Support .buildinfo files in stack ghci. #2242

Merged
merged 2 commits into from Jun 7, 2016

Projects

None yet

4 participants

@mboes
Contributor
mboes commented Jun 4, 2016

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.

To test:

$ stack unpack network
$ cd network
$ stack ghci

Without this patch the above sequence of commands doesn't work.

@mboes mboes Split resolvePackage into two functions.
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.
ba35daa
@snoyberg snoyberg added the in progress label Jun 4, 2016
@mgsloan
Collaborator
mgsloan commented Jun 6, 2016

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.

@mboes
Contributor
mboes commented Jun 7, 2016

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 readHookedInfo and updatePackageDescription, both of which are part of Cabal-the-library (and I think mandated by Cabal-the-spec, though I haven't checked). The .buildinfo files are just text files that are meant to contain a subset of the syntax for .cabal files. It's up to the user to make sure (s)he writes both .cabal and .buildinfo files in a given project in a way that is compatible with the Cabal version that Stack uses.

@mboes mboes Support .buildinfo files in stack ghci.
`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
e11c78c
@mgsloan mgsloan merged commit 96fc303 into commercialhaskell:master Jun 7, 2016

1 check failed

continuous-integration/appveyor/pr AppVeyor was unable to build non-mergeable pull request
Details
@borsboom borsboom removed the in progress label Jun 7, 2016
@mboes mboes deleted the mboes:buildinfo branch Jun 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment