Fix #4155 with pkg:libcomp in build-depends #4265
Conversation
Ericson2314
changed the title
Ericson2314
force-pushed
the
build-depends-internal
branch
from
bdd5ead
to
8646b09
Compare
Ericson2314
force-pushed
the
build-depends-internal
branch
3 times, most recently
from
15f2ddf
to
48051f9
Compare
|
Hmm OK it builds now---fixing cabal-install was way easier than I at first thought. Waiting to see what CI says. |
|
@Ericson2314 Tell me when you want review. |
|
@ezyang Sure will do. Step one is how can I best run haddock locally? I think that is causing the failure. |
|
It's pretty annoying. Workaround here: #3535 (comment) |
@ezyang that's something that you wrote :). More importantly, it looks fine to me? |
|
OH. This is a dumb Haddock thing: you're not allowed to have an asterisk at the beginning of a |
Ericson2314
force-pushed
the
build-depends-internal
branch
from
48051f9
to
440d1e3
Compare
|
Sorry to have been slow about this. Hopefully the Haddock error goes away now. |
Ericson2314
changed the title
|
Removing the WIP in hopes tests pass! :) |
|
Hmm, I do not understand the Travis error. |
Ericson2314
force-pushed
the
build-depends-internal
branch
5 times, most recently
from
e8d4281
to
ae6cb1f
Compare
Ericson2314
force-pushed
the
build-depends-internal
branch
from
a811630
to
79174af
Compare
Ericson2314
force-pushed
the
build-depends-internal
branch
from
79174af
to
c4222ee
Compare
|
Remilestoned. |
|
I won't be back for a few more days, but how should we accommodate the syntax landed in 2.0? Warning? Deprecation? |
|
I'm not sure. We may need to support it permanently. |
|
Oh when I said "deprecate", I meant ban it for min version > 2.0, but support it for min version = 2---deem it legacy syntax but not actually break existing packages. I've love to release |
|
Copying old Travis links for comparison (cause I find them hard to find after the fact)
Unfortunately the downstream travises I was most interested in are already gone. |
kmicklas
force-pushed
the
build-depends-internal
branch
from
2709dd8
to
9e0ed42
Compare
|
@Ericson2314 and I rebased this on master. We will try to finish it before it bitrots this time :) |
|
Is it possible to get this into 2.1? We'd like to ban legacy-style sub library dependencies as soon as possible, so that they are are only allowed with If so, it would probably be a good idea to break this up a bit, e.g. land the #2066 immediately. |
|
You have no objections from me, please use your discretion. |
|
This will depend on refactors that @phadej doesn't want for 2.2, so changed milestone. |
Fixes haskell#4155. We create a new `LibDependency` just used for parsing `build-depends` entries for now, but I hope it has a bright future in the brave new per-component world. Already in 'Cabal', this type will be used instead of 'Dependency' in most cases, implemented in the following commits of this PR. Used in: - Condition Trees - Querying the PackageIndex ----- Not sure about which type should have the (not)ThisPackageVersion function Also need to update some comments. Everything builds, however.
In a number of cases the build process is now interleved differently, but this seems harmless. It's probably just the new lib-dep identifiers causing a different (valid) topological sort to be used.
Eventually, configuring will be rewritten so extra constraints do note pollute the checks. When that happens this commit should be reverted.
Ericson2314
force-pushed
the
build-depends-internal
branch
from
9e0ed42
to
3c2e70e
Compare
|
Does @ezyang or @Ericson2314 plan to come back to this? |
|
I assume no. |
Working on finishing @ezyang's branch. I also cleaned up the various build-dep related fields in the process. Everything builds but tests fail.
@ezyang note I renamed
BuildDependencytoLibDependencyto matchExeDependency. I suspect when componentization is complete we might be able to remove plainDependency😃.