-
Notifications
You must be signed in to change notification settings - Fork 697
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
Allowing pkg-config to fail #6771
Comments
A solution is to introduce -- no flag
library
if has(pkgconfig)
pkgconfig-depends: libfoo
else
includes: foo.h
extra-libraries: foo
-- or some other means to figure out library needs or alternatively to allow flag defaults to be boolean expressions flag use-pkgconfig-foo
description: get foo lib config from pkg-config
-- Note: this flag is manual!
manual: True
default: has(pkgconfig)
library
[...]
if flag(use-pkgconfig-foo)
pkgconfig-depends: libfoo
else
includes: foo.h
extra-libraries: foo So there are two somewhat independent branches one can pursue:
From this two the latter is expressions is IMHO more important as picking flag assignment based on OS, Architecture or even GHC version. I also vaguely remember that @hvr might remember the details. |
Note: EDIT: After reading some issues, it seems that there is no way to make solver commit to Someone should make a table of behaviors, we ought to support all variants. I think |
I was trying to install regex-pcre and got some nonobvious errors. This was on a freshly booted system. It turns out I had neither pkg-config nor libpcre installed. But, like the error messages I struggled with, that root cause was only obvious in hindsight:
My first thought was, "if cabal is being so specific as to talk about version numbers, this has got to be a Haskell thing; why isn't it downloading pkg-config for me from Hackage?" Maybe it's because the package is mis-named? There's a Next,
Whoa. If, somewhere in there, something had said "are you sure you have libpcre installed?" I would have known what to do next; as it stands, the errors tend to make me think that something is going wrong somewhere else. Maybe I installed Or maybe my whole system is fubared? I mean, cabal says it's having trouble with So, that was what I was thinking when I had this difficulty. It's a pretty common pattern that a Hackage library relies on a system C library; I took it for granted that the system library was around, when I shouldn't have. But the error message could be more helpful. |
Unfortunately you have to learn to read the whole error message and log (it's printed, so you can figure out what's the cause):
is the key line. And note, we cannot just know which one is the thing user can try to resolve. For example in this case
you might want to actually disable the manual flag, if you have Finally, the
summarizes that out of (maybe) hundreds of dependencies the problem is probably caused by something from To summarize: you have to learn to read error output in full. It's genuinely hard to say what is preventing finding install plan. And more specifically, guiding users how to install C-libraries (with/out configuring If that's unsatisfactory to you, don't use dependencies using C-libraries. There is If you still want the solver error messages to be improved, please open new issue with constructive improvement ideas. This issue is not about that. |
I think this was resolved by #7621 |
A bug was fixed in cabal 3.8 (haskell/cabal#6771) that haskell.nix relied on for `pkg-config` in support. To work around this we added a dummy `pkg-config` that `cabal configure` now uses when haskell.nix runs it `cabal configure` internally. That returns version information for all the `pkg-config` packages in `lib/pkgconfig-nixpkgs-map.nix`. This mapping has also been expanded based on the results of searching nixpkgs for `*.pc` files. This update also includes workarounds for: haskell/cabal#8352 haskell/cabal#8370 haskell/cabal#8455
Currently,
pkgconfig-depends
imposes a hard requirement and will fail if the file is not found orpkg-config
doesn't exist. This is not portable, there are a few reasons:.pc
files downstream, causing cross-distro breakage (especially debian).pc
file may depend on the version of the libraryIn general, I believe users don't really care how cabal figures out the correct library destination etc. Of course pkg-config delivers better results than assuming e.g. FHS, but the latter still works for a majority of use cases, when pkg-config is absent.
As a result, I've come up with a template Setup.hs that sort of makes this optional. However, I feel this is rather fragile. @dcoutts reminded us that cabal-install feeds the pkg-config database into the solver and so should be able to use that information for resolution. A suggested way of triggering this was:
This, however, doesn't work, because Cabal tries to find pkg-config deps during configure stage, before the solver:
cabal/Cabal/Distribution/Simple/Configure.hs
Lines 1617 to 1641 in 867e45e
I tried commenting this out and indeed, cabal doesn't fail prematurely anymore. However, it doesn't seem to pick the alternative resolution (as in: it never disables
use-pkgconfig-foo
) and will fail at linking stage.The pkg-config database is fed during the validation phase:
Any pointers would be appreciated.
The text was updated successfully, but these errors were encountered: