-
Notifications
You must be signed in to change notification settings - Fork 698
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
[GSoC2018] Add support for multiple public libraries in a single package #5526
Conversation
Oh man this overlaps a lot with my old #4265 . I wish I could have gotten you that earlier. |
pretty (CFLibName str) = Disp.text "flib:" <<>> pretty str | ||
pretty (CExeName str) = Disp.text "exe:" <<>> pretty str | ||
pretty (CTestName str) = Disp.text "test:" <<>> pretty str | ||
pretty (CBenchName str) = Disp.text "bench:" <<>> pretty str | ||
|
||
instance Text ComponentName where | ||
parse = parseComposite <++ parseSingle |
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.
This is used in command line parsers, doesn't it? Can you add a comment, as it's surprising to see Text
instance in use. (and without corresponding Parsec
instance)
|
||
instance Text Dependency where | ||
parse = do name <- parse | ||
Parse.skipSpaces | ||
ver <- parse Parse.<++ return anyVersion | ||
Parse.skipSpaces | ||
return (Dependency name ver) |
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.
... but editing this Text
instance shouldn't affect anything.
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.
Why not? Isn't it used for display
? display
appears in quite a few places
|
||
instance Parsec Dependency where | ||
parsec = do | ||
name <- lexemeParsec | ||
ver <- parsec <|> pure anyVersion | ||
return (Dependency name ver) |
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.
Note: we need to case on askCabalSpecVersion
.
Also a dumb question, are all internal sublibraries public with this change? EDIT i.e. can be dependent upon. |
@phadej Yup. But I'll add a |
@Ericson2314 Yeah, I discovered that pr halfway through GSoC (and I actually tried to rebase it), but at that point my work diverged too much from that :-/ (I use I did not manage to separate the dependency-as-constraint from the dependency-dependency as you did, but I really think it should be done: https://github.com/fgaz/gsoc/blob/master/2018/final-report.md#the-dependency-as-constraint-problem |
Glad you found it and it was of some use :) |
@fgaz is there any part which can be separated into own PR and merged already (even it's little or even no use by itself alone)? |
@phadej yup, that and the GivenComponent one probably. Also note that the LibraryName refactor could be much more complete, but I ran into some problems (I probably just forgot something. I'll have to recheck why the tests broke) |
Is it ok if I add the visibility field in another pr after the merge, so we merge soon and avoid conflicts? |
@fgaz Yes, sure. |
56a3c0d
to
b57838f
Compare
|
||
instance Parsec Dependency where | ||
parsec = do | ||
name <- lexemeParsec | ||
libs <- option [LMainLibName] |
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.
Note: this should be guarded by askCabalSpecVersion
or is only direct dependencies are passed. Anyway, build-type: Custom have to we thought out properly, as there we have to speak with old Cabal code. |
@phadej Just tested it and only direct deps are passed |
@fgaz that's good news 👍 |
…nfigure` In the course of 4466310 (see haskell#5526) the `Setup.hs haddock` CLI was extended to allow component ids to be passed as positional arguments. However, `autoconfUserHooks` which is used in case of `build-type: Configure` wasn't updated accordingly, and consequently this caused `new-haddock` to break for packages using `Configure`. Fixes haskell#5503
…nfigure` In the course of 4466310 (see haskell#5526) the `Setup.hs haddock` CLI was extended to allow component ids to be passed as positional arguments. However, `autoconfUserHooks` which is used in case of `build-type: Configure` wasn't updated accordingly, and consequently this caused `new-haddock` to break for packages using `Configure`. cc @alexbiehl Fixes haskell#5503
…nfigure` In the course of 4466310 (see #5526) the `Setup.hs haddock` CLI was extended to allow component ids to be passed as positional arguments. However, `autoconfUserHooks` which is used in case of `build-type: Configure` wasn't updated accordingly, and consequently this caused `new-haddock` to break for packages using `Configure`. cc @alexbiehl Fixes #5503 (cherry picked from commit 86dabda)
@fgaz Do you want us to review now? :) |
@ezyang Sorry, not yet. Just wait a literal couple of days |
"url":"pull/5526", "account":"haskell", "repo":"cabal", "commit": "63f4c37a1b0a267029e5b9e12d58fb0759a22e11", "tag":"linux-7.6.3" }
"url":"pull/5526", "account":"haskell", "repo":"cabal", "commit": "63f4c37a1b0a267029e5b9e12d58fb0759a22e11", "tag":"linux-7.8.4" }
"url":"pull/5526", "account":"haskell", "repo":"cabal", "commit": "63f4c37a1b0a267029e5b9e12d58fb0759a22e11", "tag":"osx-7.8.4" }
"url":"pull/5526", "account":"haskell", "repo":"cabal", "commit": "887eb3352fc6f923e46bc3cb24c0de89292165bb", "tag":"linux-7.10.3" }
"url":"pull/5526", "account":"haskell", "repo":"cabal", "commit": "887eb3352fc6f923e46bc3cb24c0de89292165bb", "tag":"linux-8.0.2" }
"url":"pull/5526", "account":"haskell", "repo":"cabal", "commit": "a9fee729d714c06518183ad67a9fb4c4c44f14b9", "tag":"linux-8.0.2" }
The old --dependency could only do --dependency=pkg=cid, but with public sublibraries this will become insufficient. Now there is the option to also specify a component name using --dependency=pkg:component=cid
Before, a 3-tuple was used
This gives us more type safety when dealing with libraries only
Create a new syntax for depending on any library of any package. The syntax is build-depends: pkgname:{pkgname, sublibname} -any where the second `pkgname` specifies a dependency on the main unnamed library. Closes haskell#4206.
Dependency is used in two seemingly related but now incompatible ways: * As a dependency specification ("I want this component from this package, version range xy") * As a constraint ("Package p must be in version range xy") This commit begins to separate the two concepts.
We generated them both the old way (only internal libs) and the new way (arbitrary sublibraries), leading to this: $ cabal new-configure my-package -v [...] Component graph for my-package-0.2.0.0: component exe:my-exe component my-package-0.2.0.0-inplace-my-exe include base-4.11.1.0 include base-4.11.1.0 include word8-0.1.3-968d6922e82a4ae480d10bc205e047a27af7804ae8fb577c4b6eeb868f99ee3b include word8-0.1.3-968d6922e82a4ae480d10bc205e047a27af7804ae8fb577c4b6eeb868f99ee3b [...] ...which didn't have any effect on the build except for some duplicate output, but could lead to problems in the future. Now we only generate them the new way.
This reverts commit 1c4ad06. The previous commit fixed it
a9fee72
to
533b7cf
Compare
It's ready, but appveyor continues to fail with this error:
Is that normal/something that happens often? edit: I don't have a windows machine on which to test it. |
29970a5
to
533b7cf
Compare
Congrats!!! |
(cherry picked from commit 4d2ca52)
This is my work for Google Summer of Code 2018.
It adds support for multiple public libraries, as described in #4206.
See https://github.com/fgaz/gsoc/blob/master/2018/final-report.md for a more detailed report. I'll expand a bit this description shortly.
There are still a few nonessential things to do and some things to clean, so don't review yet! (see the link above or the checklist below). It should all work though.Go ahead!Closes #4206
/cc @ezyang @23Skidoo
Things to fix/clean/update before merging:
After merging (better to merge soon and avoid to let it rot) (moved to #5660)
packageNameToUnqualComponentName
)cabal init
to take into account sublibraries when populating build-depends