-
Notifications
You must be signed in to change notification settings - Fork 704
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
Per component copy #3066
Closed
Closed
Per component copy #3066
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
35101d8
to
b50b97b
Compare
@ezyang thank you so much! |
b50b97b
to
b7811f1
Compare
(If someone wants this in 1.24 they'll have to backport it past #2780. It won't be trivial, but maybe it won't be too hard either.) |
…ctories. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
This custom setup ensures that if we are bootstrapping, we will use the most recent version of Cabal. (Without setup, cabal-install will force usage of an old version of Cabal.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Convenience libraries are package-private libraries that can be used as part of executables, libraries, etc without being exposed to the external world. Private libraries are signified using the library foo stanza. Within a Cabal package, the name convenience library shadows the conventional meaning of package name in build-depends, so that references to "foo" do not indicate foo in Hackage, but the convenience library defined in the same package. (So, don't shadow Hackage packages!) This commit implements convenience libraries such that they ARE installed the package database (this prevents us from having to special case dynamically linked executables); in GHC 7.10 and later they are installed under the same package name as the package that contained them, but have a distinct "component ID" (one pay off of making the distinction between component IDs and installed package IDs.) There is a "default" library which is identified by the fact that its library name coincides with the package name. There are some new convenience functions to permit referencing this. There are a few latent bugs in this commit which are fixed in later commits in this patchset. (Those bugfixes required a bit of refactoring, so it's clearer if they're not with this patch.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
This commit is a number of refactorings that I needed to do while fixing bugs with internal libraries support. - With internal libraries, it becomes especially clear that cabal_macros.h and Paths_foo.hs need to be done per-component. It is done! This change breaks BC in an important way: the preprocessor interface now takes a ComponentLocalBuildInfo along with the BuildInfo and LocalBuildInfo. This means that if you implemented a custom preprocessor, or called 'preprocessComponent' in a custom Setup, you will have to make sure you pass the right ComponentLocalBuildInfo. Some sub-notes: - While I was mucking about cabal_macros.h, I updated it to have two new macros: CURRENT_COMPONENT_ID (an alias for CURRENT_PACKAGE_KEY, but using modern terminology) and LOCAL_COMPONENT_ID (which refers to the public library; we use this in Cabal's test suite but it's unclear what the general utility of this is. See the TODO.) - checkForeignDeps has a hack where we hardcode the cabal_macros.h of the main library. If we did the foreign dep check for every component individually that would be better, but I didn't want to roll it into this patch. - The other piece I needed for internal libraries was per-component install directories; otherwise, internal libraries clobber each other. absoluteInstallDirs now takes a ComponentId, which is used to determine what '$libname' expands to. Generally, InstallPaths must be computed per component, c.f. haskell#2836. We're not TRULY per-component install paths, since some files are installed for the "per-package" InstallPaths (the one we computed for the library as a whole), but for libraries we have to compute InstallPaths for each one. - While doing this, ComponentLocalBuildInfo grew a new 'componentId' field for non-library things. This lets us treat InstallPaths expansion uniformly. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
This commit fails its tests, because dynamic executables linked against internal libraries aren't handled correctly yet. I had to do more refactoring to handle this correctly, so it's in a separate commit. Some refactoring in this one for identifying public libraries as opposed to internal ones. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
1. 'componentsConfigs' no longer is a graph identified by ComponentNames, but by ComponentIds (this is because, eventually, they'll be identified uniquely by a UnitId, but NOT by a ComponentName.) This caused some modest use-site changes but nothing major. 2. To make it easier to get the Component given a ComponentLocalBuildInfo, I added a new field 'componentLocalName' which records the original source-level name of the 'ComponentLocalBuildInfo'. 3. Rewrote the test in 'depLibraryPaths' which checks if a component is "internal" or not (arguably this should be factored into a common function, but at the moment it only occurs in one place.) 4. Finally, 'depLibraryPaths' correctly takes the transitive closure of internal dependencies (rather than assuming that an internal dependency must be on the public library). Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Also, unconditionally pass -v to cabal in package-tests. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
A lot of tooling (Cabal's included) assumes that if something in the installed package database has 'name: foo', it is a valid choice if we are dependency solving for 'foo'. If we always name internal libraries something else, this tooling will not get confused. So let's help them out. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
haskell#1893) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
This test-case was lifted straight from the Cabal manual. It also tests if buildinfo is handled correctly. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
b7811f1
to
eedd07f
Compare
This got folded into #3022. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Accept components to copy in ./Setup copy, fixes #2780.
This is based off of #3022 (which has a very useful refactoring.) Only the last commit is relevant.