cabal new-build is utterly unusable for cross-compilation
#4939
Comments
|
Just to note the current possible work-around. Because flags are applied to all project local sources, you can work around this, by asking cabal to pull and unpack the package and then add it to the |
|
Just going to leave this here, because I know I'd likely forget where it was. In This is called in and this is where I believe we loose the information about I believe someone with a deeper knowledge of the plan elaboration, could probably point how to solve this properly. |
23Skidoo
changed the title
new-build is utterly unusable*new-build is utterly unusable for cross-compilation
|
#4972 should help with this. |
|
@ezyang I should give this a try. Will report back. |
|
Alright, so I can put the following into my While this does help a little, as it passes I'm fairly sure we want to push the program locations and program options unconditional into the dependencies as well if they are provided via the |
|
Another issue now is clearly, that I have a Ideally though this would just be |
This should help with haskell#4939. `--with-PROG` flags should be applied to every package. If we change hsc2hs via `--with-hsc2hs=` or any other program and similarly `--hsc2hs-options` should also be provided to that program. Same holds for `--PROG-options`. Because we do no inherit the properties from AllPackages for LocalPackages, we need to have the set of programs and options in both.
This should help with haskell#4939. `--with-PROG` flags should be applied to every package. If we change hsc2hs via `--with-hsc2hs=` or any other program and similarly `--hsc2hs-options` should also be provided to that program. Same holds for `--PROG-options`. Because we do no inherit the properties from AllPackages for LocalPackages, we need to have the set of programs and options in both.
|
This was fixed with #5018 |
With
new-buildwe apply the--with-PROGand--PROG-option(s)only to the current project local package. As such, they are not pushed down to dependencies. To illustrate this:so we have
a -> b -> danda -> c -> dIf we try to build with new-build:
we compile
awithmyshc2hs --cross-compile, but forb,canddwe get nohsc2hsin the package database, and as such do the canonical lookup, which gives ushsc2hs. Of course we are missing--cross-compilenow as well.Let us assume without restriction
chas some.hscfiles.cnow fails to compile, and subsequently the complete build fails. Worse, I have no option to provide those via thecabal.projectfile, as theprogram-optionsandprogram-locationsstanzas are seemingly not picked up as nodes of thepackagestanza.Example:
This ends up as
I do understand that we can't push down arbitrary flags into dependencies. If they take part in the hash, this would mean that we might end up trying to rebuild packages that ship with ghc, but are not re-installable.
While the
packagestanza may work if you want to selectively set some value for a specific package, even ifprogram-locationsandprogram-optionsworked inside ofpackagestanzas, I would end up needing to add them for each and every dependency. Should any dependency in the project change, I would need to update theproject.cabalfile again, and it would just keep on growing with lots of repetition. I don't see this as a solution that would provide a user experience I would appreciate.The other option I see is to push
--with-PROGand--PROG-optionsdown into the dependencies, and if we hit packages that are shipped with GHC, we just accept them and do not try to rebuild them. If the user tried to mess too hard with his install here, it his own fault things break.We could extract the CC and LD values from GHC info.
cabal clearly knows them from the
ElaboratedSharedConfighsc2hsis going to be a bit more tricky, as it's not listed in GHC's commands. We could of course add it, but after allhsc2hs, asalexandhappyare build tools that should not be coupled too tightly with GHC as far as I understood @hvr. And where does would this end? Adding each and every tool that ghc used during it's own build (and the respective flags) to GHC's info output?Related issues: #2997, #4925, #4844, #4829
The text was updated successfully, but these errors were encountered: