Skip to content
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
wants to merge 29 commits into from
Closed

Per component copy #3066

wants to merge 29 commits into from

Conversation

ezyang
Copy link
Contributor

@ezyang ezyang commented Jan 19, 2016

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.

@ezyang ezyang force-pushed the per-component-copy branch from 35101d8 to b50b97b Compare January 19, 2016 08:35
@ezyang
Copy link
Contributor Author

ezyang commented Jan 19, 2016

CC @snoyberg, @mgsloan, @lukehoersten

@lukehoersten
Copy link
Member

@ezyang thank you so much!

@ezyang
Copy link
Contributor Author

ezyang commented Jan 19, 2016

(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.)

ezyang added 24 commits February 1, 2016 19:16
…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>
@ezyang
Copy link
Contributor Author

ezyang commented Mar 29, 2016

This got folded into #3022.

@ezyang ezyang closed this Mar 29, 2016
@ezyang ezyang deleted the per-component-copy branch April 8, 2016 02:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

copy command fails when building only some components
3 participants