Solver: Support dependencies on sub-libraries (issue #6039) #6812
Conversation
|
@fgaz what else is needed to be done to make or is this a "handling of installing packages" which @grayjay mentions in #6047 (comment) If so, feel free to merge as soon as CI is green. |
|
Also remember to write a chengelog entry (See |
|
@grayjay do you have 2FA enabled on GitHub. Looks like you are not a collaborator of Cabal anymore (so I cannot assign issues to you). I'd like to add you back. |
|
@grayjay I see you didn't pass As per #6047 (comment) we should either do that or fail early, otherwise this still fails late in the build on <8.8 |
|
Looks like there's a conflict. I'll rebase again shortly. |
This commit tracks dependencies on sub-libraries by extending the functionality for tracking executables that was added in e86f838. It also starts adding support for library visibility, though it currently only works for source packages. There is a TODO for handling installed packages. This commit handles visibility similarly to the way that the buildable field is handled currently. It only checks whether a component is made private by the current environment and flag constraints at the start of dependency solving. This means that the solver can treat a component as visible when the visibility is controlled by an automatic flag, and the build can fail later, depending on the value that is chosen for the flag. Fixes haskell#6038.
This commit also refactors the Dependencies type so that it can represent any combination of dependencies, buildability, and visibility.
|
rebased. |
|
And here's the line that should be changed: cabal/cabal-install/Distribution/Client/ProjectPlanning.hs Lines 3415 to 3417 in 06c3eff Ideally we'd set it to true only for GHC <8.8, so that we'd still have Cabal's sanity checks for newer GHCs |
|
This should work. Please take a look @phadej |
|
@phadej I just force-with-lease pushed and only later realized that this is your branch, sorry |
|
Can I disallow that globally. I never opted-in for that
… On 22. May 2020, at 19.50, Francesco Gazzetta ***@***.***> wrote:
@phadej I just force-with-lease pushed and only later realized that this is your branch, sorry
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I repushed my version. Sorry for the lsot commit @fgaz, but with over hunded people with write access, I cannot permit pushing to my repository. It's disastrous, not convenient. This is why I opened a separate PR in the first place. Please DO NOT PUSH INTO OTHERS BRANCHES BEFORE ASKING FOR PERMISSION. |
|
And allow edit by maintainers setting doesn't seem to be preserved. :( |
Nothing lost :) I opened another pr with my change: #6836
Wow, a hundred already? That's a lot Sorry for pushing on your branch, I saw the "Add more commits by pushing to the pr-6047 branch on phadej/cabal." message and assumed it was ok to do that. I can't help but notice that this is yet another flaw in the PR model. Multiple people cannot iterate on a patch without opening a million prs. |
|
collaboration needs communication, pushing into branches "owned" by others without an agreement is not polite. |
Rebased #6047