-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change imports to work with functored AST #8084
base: main
Are you sure you want to change the base?
Conversation
Unfortunately due to https://gitlab.haskell.org/ghc/ghc/-/issues/19507 this cannot be perfectly seamless
Is it possible to get this building properly with the CI? |
I'll rebase it. I would think it should work with |
8706396
to
1b7bfbd
Compare
Oh good, this does work with the old deps too as confirmed by CI. |
Can you add to this PR stanzas in cabal.project that force it to use the modified versions of pandoc-types and pandoc-lua-marshall (from the repositories)? |
bcde758
to
5d92ceb
Compare
Fix conflicts and then re-added that commit. From my local building, We seems to be building with and without the other PRs, as intended. |
@jgm Tests failed because of a cabal install bug. I worked around the bug by checking out the repos manually. I would be happy to do a call any answer any questions you have, walk you through things live, if they helped you review this. |
@Ericson2314 Can you point me to documentation of the cabal install bug, and instructions for working around it? |
@jgm Sorry I keep on missing your replies! haskell/cabal#6888 is the issue. I think the workaround was just to go into those repos and check out the right branch/commit by hand. |
Yes, I think you need to use |
@jgm Should I push some tags then? I would have to push more if you want changes to any of the constituent PRs. |
Yes, without the tags, we don't have CI testing how it all fits together. |
(actually revs not tags) to work around haskell/cabal#6888
Oh! One can just put in a commit hash as a "tag". That's not so many hops to jump through then :). Done. (I did it blind in github, knock on wood there's not a silly typo!) |
Ugh ugh ugh... I understand as a maintainer it's much less stressful to let CI build things instead of trying them out locally, but perhaps building locally is the path of least resistance at this point? I would be happy to take some time to go on a call and answer any questions in real time if that is of any use. |
Just set the version of your version of pandoc-types to 1.22.2.1 for now. |
@jgm erm... I think it is |
OK, I jumped to conclusions. I see what is going on. If I could eliminate the separate "dependencies only" step in the CI, that would fix it -- that step was needed because of a cabal-install bug that has been fixed a while back, I think, so let me look into this. Meanwhile I built this locally. Results: Compiler warnings:
|
The cabal fix I need to avoid a separate
|
Previously we had to work around a cabal-install bug that caused `-Werror` to react to dependencies as well as local packages, but this is fixed in cabal 3.8.1.0. There are some cases in which building dependencies only doesn't work (see #8084).
Thanks @jgm! And thanks for reminding me about those tests. |
I just pushed a CI change that should help, so if you rebase against master, hopefully the CI will build. |
Unfortunately due to https://gitlab.haskell.org/ghc/ghc/-/issues/19507
this cannot be perfectly seamless