Skip to content
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

Support .buildinfo files in stack ghci. #2242

Merged
merged 2 commits into from
Jun 7, 2016

Conversation

mboes
Copy link
Contributor

@mboes 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.

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.
@mgsloan
Copy link
Contributor

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
Copy link
Contributor Author

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.

`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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants