-
Notifications
You must be signed in to change notification settings - Fork 696
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
Try each pkg-config query separatedly #9134
Try each pkg-config query separatedly #9134
Conversation
@jasagredo Thank you for the initiative! Would you mind adding QA notes and check the boxes in the description? :) |
A bit of git blame turns up some previous discussion on the PR that added the individual fallback. It would be good to get this reasoning into the code in comments! #8496 (comment) |
Related #8930 |
bf9de80
to
4b87276
Compare
I've modified the logic to fallback to individual query if the length of the returned list doesn't match the length of the query, which is precisely what happens on Windows. On any other flows, the behavior should be the same. |
I'm good with this, @michaelpj? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Personally I think the argument for doing the batch query didn't seem that strong, and it seems to regularly cause problems. So I'd be in favour of the original change in this PR, but perhaps it's best to be conservative. Unless @gbaz wants to weigh in? |
pkgConfigDbFromList . catMaybes <$> mapM (getIndividualVersion pkgConfig) pkgNames | ||
if exitCode == ExitSuccess && length pkgNames == length pkgList | ||
then (return . pkgConfigDbFromList . zip pkgNames) (lines pkgVersions) | ||
else -- if there's a single broken pc file the above fails, so we fall back into calling it individually |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would help to add the second reason for the fallback to this comment.
I have not yet confirmed my suspicions, but I think this is due to faulty pkg-configs installed in MSYS2, see this. In particular:
|
@jasagredo: how can we help to move this forward? |
I think the right way forward is to:
2a. GHCup in Windows checks if 2b. Cabal in Windows detects if I do think that GHCup should fail in Windows if a non-appropriate Probably @hasufell has some thoughts on this. |
GHCup doesn't track your system tools. These things are installed by the powershell bootstrap script and only on windows, because of how special the situation is with msys2. But in general, this is not GHCup's business to take care of your non-Haskell stuff.
It does not. |
Sorry @hasufell it seems I was confused with the scope of the responsibilities for GHCup. However, in the case of GHCup bootstrapping MSYS2, would it make sense to install an appropriate pkg-config there? In any case, if we cannot rely on an appropriate TL;DR: I propose setting those 2 env vars when cabal calls What do you think? @Mikolaj |
We currently install The end user might however uninstall it or install arbitrary other ones. This is just a convenience feature in the bootstrapper. We can't control what pacman has installed. Cabal should be maximally compatible here. |
@hasufell alright, so this PR will make it work in presence of |
15e8fc8
to
2d6dcd9
Compare
Makes sense. Thank you all for the effective discussion. @jasagredo, before you set the merge label, does the description of the PR still match the new code? Do you think it makes sense to ping all four reviewers and tell them what changed since they've reviewed last time? |
…query length MinGW's pkg-config returns only one version even if queried for multiple libraries.
2d6dcd9
to
9f15045
Compare
Though honestly I think we should only query individual pkgconf's separately going forward. Does cabal really needs all the pkgconf's even? I also wonder what the use-case is? |
The solver needs to know the installed packages on the system so it can make use of them in creating a build-plan. They are needed together rather than individually so that the solver can be pure rather than performing IO queries over the course of its execution. |
At least pkgconf-2.0 seems to revert to the old pkgconf-1.8 behavior But quite a few distros are currently on pkgconf-1.9 so we really need to fix this properly |
Perhaps it does help? I have not tried (I'm not developing on windows nowadays). However the environment variables flags should be mandatory in Windows and harmless in Linux. Mingw has this weird inconvenience where there are 3 pkgconf implementations and each one produces different outputs. |
@jasagredo (and presumably @grayjay) suggest to backport this to 3.10 branch for the 3.10.3.0 release. Let me mark it provisionally with a label, create a backport PR to see the conflicts and let's discuss. |
@mergify backport |
❌ No backport have been createdNo destination branches found |
@mergify backport 3.10 |
✅ Backports have been created
|
The conflicts don't seem terrible. |
Here's the relevant comment by @grayjay: #9520 (comment) |
Try each pkg-config query separatedly (backport #9134)
MinGW's pkg-config returns only one version even if queried for multiple libraries. This PR makes it so that cabal will invoke pkg-config once for each requested library if the result is not of the expected length, therefore supporting these pkg-config implementations, in particular
mingw-w64-x86_64-pkgconf
(which is also installed by GHCup when bootstrapping MSYS2).In the same spirit as rust-lang/pkg-config-rs#92, as we also are not GCC, we also set
PKG_CONFIG_ALLOW_SYSTEM_(CFLAGS|LIBS)
when callingpkg-config
QA Notes
Building a package that depends on more than one library provided by
pkg-config
on MinGW should now be able to find the required library.