Support .buildinfo files in stack ghci. #2242
Conversation
The gruntwork is now done by `packageFromPackageDescription`. The idea is that if you already have a resolved `GenericPackageDescription`, i.e. a `PackageDescription`, then you should still be able to get a `Package` out of it.
|
Cool, resolving this'd make a lot of people happy, I didn't realize it'd be so simple. Are there any possible interactions between buildinfo files and Cabal versions? Like if stack updates to building against Cabal-1.24, will it read buildinfo files from Cabal-1.18? In other words, unlike cabal-install, the Cabal that stack is built against can vary with the one that's used for building. |
|
This patch doesn't depend on any new Cabal modules that Stack didn't depend on previously. The only new function it depends on is |
`Distribution.Simple` based `Setup.hs` sometimes create `<package>.buildinfo` files as an artifact of the configure phase. This is the case in particular when using the autoconf hooks. Since this is an internal detail private to any given package's `Setup.hs`, Stack shouldn't (and doesn't) need to care or be aware of this. But `stack ghci` does, since in that use case we're not using Cabal to build - we're taking care of the build ourselves. In particular, ignoring the `<package.buildinfo` file can mean that a successful build using `stack build` can't be replicated using `stack ghci`. E.g. in the case of the `network` package, the set of C files to build is decided at configure time, based on the current platform. So the `c-files` stanza in the .cabal file is not complete. This in turn means `stack ghci` isn't aware of all object files it has to link in, leading to obscure link errors (see #1239). See [1] for more on .buildinfo files. Fixes #2239. [1]: https://www.haskell.org/cabal/users-guide/developing-packages.html#system-dependent-parameters
4 participants
Distribution.SimplebasedSetup.hssometimes create<package>.buildinfofiles as an artifact of the configure phase.This is the case in particular when using the autoconf hooks. Since
this is an internal detail private to any given package's
Setup.hs,Stack shouldn't (and doesn't) need to care or be aware of this. But
stack ghcidoes, since in that use case we're not using Cabal tobuild - we're taking care of the build ourselves. In particular,
ignoring the
<package.buildinfofile can mean that a successfulbuild using
stack buildcan't be replicated usingstack ghci.E.g. in the case of the
networkpackage, the set of C files to buildis decided at configure time, based on the current platform. So the
c-filesstanza in the .cabal file is not complete. This in turnmeans
stack ghciisn't aware of all object files it has to link in,leading to obscure link errors (see #1239).
See 1 for more on .buildinfo files.
Fixes #2239.
To test:
Without this patch the above sequence of commands doesn't work.