-
Notifications
You must be signed in to change notification settings - Fork 701
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
Problems using cabal-install with backpack #6005
Comments
/cc @ezyang |
I’m getting the same problem when I try to build |
This is even worse than I originally thought it was. If I have any project that depends on |
As a workaround, if I add a cabal.project file to pull the source code from github, everything works fine:
|
Hmmm... with
And then with
Weird. This more verbose error doesn't even come from the same module. |
Keep in mind, this failure only happens when I use |
@andrewthad I'm having a similar problem when I try to depend on (I'm also getting a bad interface file warning when I try to run |
Interesting. It seems like this is an even bigger problem than I had assumed it was. If this isn't going to be addressed any time soon, it's probably worth mentioning in the user manual that libraries that use backpack in any capacity should not be uploaded to hackage for the time being. |
I've root caused the problem: it indeed is because we are loading the wrong interface, because Cabal is installing package files which point at the wrong location. In the package conf for an instantiated package, I see that it provides |
Previously, we would compute elabInstallDirs once when configuring a component, and then reuse the exactly same install directories for every instantiation of the package. But this is wrong, since we're installing the header/object files for each instantiation to a different directory. We refactor install directory computation into a helper function and then call it again at instantiation time to refresh the install directories. For some reason, this bug ONLY manifests for packages installed from Hackage; it seems install dirs are not respected for inplace packages. Fixes haskell#6005 Signed-off-by: Edward Z. Yang <[email protected]>
…nts (#6317) * Restructure Includes3 tests so that I can also test Hackage case. Signed-off-by: Edward Z. Yang <[email protected]> * Compute correct install directories for instantiated Backpack components Previously, we would compute elabInstallDirs once when configuring a component, and then reuse the exactly same install directories for every instantiation of the package. But this is wrong, since we're installing the header/object files for each instantiation to a different directory. We refactor install directory computation into a helper function and then call it again at instantiation time to refresh the install directories. For some reason, this bug ONLY manifests for packages installed from Hackage; it seems install dirs are not respected for inplace packages. Fixes #6005 Signed-off-by: Edward Z. Yang <[email protected]> * Test fix Signed-off-by: Edward Z. Yang <[email protected]> * Copy backpack version-guard from other backpack testcases
FYI the docs still seem to have a warning about this issue: https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-sdist that should probably be removed if this is fixed? |
@DanielG: am I right the warnings in the docs are gone now? |
With Backpack interoperability problems now resolved, the related warnings in the documentation can probably be removed. [1] Drops the sole warning located by a text search for "6005". [1] haskell#6005 (comment)
Huh. Thanks. :) |
With Backpack interoperability problems now resolved, the related warnings in the documentation can probably be removed. [1] Drops the sole warning located by a text search for "6005". [1] #6005 (comment)
With Backpack interoperability problems now resolved, the related warnings in the documentation can probably be removed. [1] Drops the sole warning located by a text search for "6005". [1] #6005 (comment) (cherry picked from commit 1042ae4)
Hi,
I'm trying to use
cabal
with a backpack-ified library, viz.archive-tar
(which provides a signature forarchive-sig
. Unfortunately, the build fails withYou can see a branch with a failing project here. I'm happy to provide more debug information.
Thanks!
The text was updated successfully, but these errors were encountered: