Per component copy#3066
Closed
ezyang wants to merge 29 commits intohaskell:masterfrom
Closed
Conversation
35101d8 to
b50b97b
Compare
Contributor
Author
Member
|
@ezyang thank you so much! |
b50b97b to
b7811f1
Compare
Contributor
Author
|
(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
Contributor
Author
|
This got folded into #3022. |
This file contains hidden or 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
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.