Handle missing library in haskell_toolchain_library #882
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mboes
approved these changes
May 21, 2019
mboes
added a commit
that referenced
this pull request
May 22, 2019
With `haskell_cabal_library` (added in #882), we have the ability to make one-shot calls to Cabal, assuming, 1. that the sdist for the Cabal package has been fetched and unpacked, and 2. that dependencies have been declared correctly. Declaring these dependencies by hand for all packages on Hackage is a fool's errand. This commit uses Stack to, 1. resolve package names to package versions using the given snapshot, 2. fetch the sdist and unpack it, 3. find out the dependency graph and generate a `BUILD` file encoding it. Stack only outputs dependency information in GraphViz format. So have to parse that. This assumes Stack is in the `PATH` (hence build is non-hermetic). But it's pretty unreasonable to build our own Stack inside a workspace rule (Bazel's build engine doesn't work there). The best we can do is download prebuilt binaries, which we can do in the future (after figuring out how to seamlessly work on NixOS). Closes #874.
Merged
mboes
added a commit
that referenced
this pull request
May 22, 2019
With `haskell_cabal_library` (added in #882), we have the ability to make one-shot calls to Cabal, assuming, 1. that the sdist for the Cabal package has been fetched and unpacked, and 2. that dependencies have been declared correctly. Declaring these dependencies by hand for all packages on Hackage is a fool's errand. This commit uses Stack to, 1. resolve package names to package versions using the given snapshot, 2. fetch the sdist and unpack it, 3. find out the dependency graph and generate a `BUILD` file encoding it. Stack only outputs dependency information in GraphViz format. So have to parse that. This assumes Stack is in the `PATH` (hence build is non-hermetic). But it's pretty unreasonable to build our own Stack inside a workspace rule (Bazel's build engine doesn't work there). The best we can do is download prebuilt binaries, which we can do in the future (after figuring out how to seamlessly work on NixOS). Closes #874.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
haskell_toolchain_libraryexpects the incoming lists of static and dynamic libraries to pair up exactly. As detailed in #881 this is currently not the case. This PR does not resolve issue #881. However, it makes the code in question more robust by making sure that in case a library component is missing the right libraries are paired up. E.g. it will preventlibCffi.ato be paired up withlibHSrts-ghc*.so.