This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 29 Mar, 2016 5 commits
    • Edward Z. Yang's avatar
      90119466
    • Edward Z. Yang's avatar
      Unconditionally turn on package name munging for components. · 516abff9
      Edward Z. Yang authored
      
      
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      516abff9
    • Edward Z. Yang's avatar
      Refactor ComponentLocalBuildInfo, fixing rpaths with internal libraries. · ca93c471
      Edward Z. Yang authored
      
      
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      ca93c471
    • Edward Z. Yang's avatar
      Per-component cabal_macros.h (#1893) and install paths · 90e908b8
      Edward Z. Yang authored
      
      
      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. #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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      90e908b8
    • Edward Z. Yang's avatar
      Implement "convenience libraries", fixes #269. · 2040c1c9
      Edward Z. Yang authored
      
      
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2040c1c9
  2. 12 Mar, 2016 1 commit
  3. 29 Feb, 2016 1 commit
  4. 27 Feb, 2016 1 commit
  5. 20 Feb, 2016 3 commits
  6. 19 Feb, 2016 3 commits
  7. 13 Feb, 2016 2 commits
  8. 30 Jan, 2016 1 commit
  9. 27 Jan, 2016 1 commit
    • kristenk's avatar
      Improve algorithm for choosing flags with './Setup configure' · 6d42e6ed
      kristenk authored
      Cabal previously tried all flag combinations, which was very slow.  The new
      algorithm assigns one flag at a time, and backtracks when a flag introduces a
      dependency that is unavailable.
      
      The new algorithm handles the Buildable field by adding an extra conditional at
      the top level of each component that represents the condition for which the
      component is buildable.  Since all dependencies go under the "then" branch, they
      are only required when a flag choice makes the component buildable.  The buildable
      logic is taken from the cabal-install dependency solver.
      
      This commit also changes the error message that is shown when dependencies are
      missing.  Previously, Cabal printed the shortest list of missing dependencies
      from a single flag assignment.  Now it takes the union of all dependencies that
      caused it to backtrack when trying different combinations of flags, which
      requires less searching.
      6d42e6ed
  10. 25 Jan, 2016 1 commit
  11. 16 Jan, 2016 4 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Distinguish between component ID and unit ID. · ef41f44e
      Edward Z. Yang authored
      
      
      GHC 8.0 is switching the state sponsored way to specify
      linker names from -this-package-key to -this-unit-id, so
      it behooves us to use the right one.  But it didn't make
      much sense to pass ComponentIds to a flag named UnitId,
      so I went ahead and finished a (planned) refactoring
      to distinguish ComponentIds from UnitIds.
      
      At the moment, there is NO difference between a ComponentId
      and a UnitId; they are identical.  But semantically, a
      component ID records what sources/flags we chose (giving us enough
      information to typecheck a package), whereas a unit ID records
      the component ID as well as how holes were instantiated
      (giving us enough information to build it.)  MOST code
      in the Cabal library wants unit IDs, but there are a few
      places (macros and configuration) where we really do
      want a component ID.
      
      Some other refactorings that got caught up in here:
      
          - Changed the type of componentCompatPackageKey to String, reflecting the
            fact that it's not truly a UnitId or ComponentId.
      
          - Changed the behavior of CURRENT_PACKAGE_KEY to unconditionally
            give the compatibility package key, which is actually what you
            want if you're using it for the template Haskell trick.  I also
            added a CURRENT_COMPONENT_ID macro for the actual component ID,
            which is something that the Cabal test-suite will find useful.
      
          - Added the correct feature test for GHC 8.0 ("Uses unit IDs").
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      ef41f44e
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Remove instantiated-with and related support work. · 15e0e717
      Edward Z. Yang authored
      
      
      Backpack is going to have to rewrite this functionality.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      15e0e717
  12. 10 Jan, 2016 2 commits
    • Edward Z. Yang's avatar
      4fc9588d
    • Edward Z. Yang's avatar
      Properly assign component ID/build dir for LibV09 test libraries · 18fcd9c1
      Edward Z. Yang authored
      
      
      Cabal's LibV09 support has always been a bit skeevy.  The general
      idea was that a detailed-0.9 test-suite is built as a library
      and an Cabal-provided stub executable.  In particular, the test suite
      library must be installed to the installed package database so that the
      executable can be compiled.
      
      Old versions of Cabal did something very skeevy here:  they installed
      the test library as a "package", with the same package name as
      the "test-suite" stanza; furthermore, they built the products
      into the same directory as the library proper.
      
      Consequently, a lot of bad things could happen (both of which I've
      added tests for):
      
          1. If the name of the test suite and the name of some other
          package coincide (and have the same version), they will clobber
          each other.  In GHC 7.8 and earlier, this just flat out
          kills the build, because it will shadow.  There's an explicit
          test to make sure test suites don't conflict with the package
          name, but you can get unlucky.
      
          2. The test suite library is built into the same directory
          as the main library, which means that if the test library
          implements the same module name as something in the main
          library it will clobber the interface file and badness
          will ensue.
      
      This patchset fixes both of these issues, by (1) giving internal
      test libraries proper names which are guaranteed to be unique
      up to Cabal's dependency resolution, and (2) building the test
      suite library into a separate directory.
      
      In doing so, it also lays the groundwork for other types of
      internal libraries, e.g. #269, as well as extra (invisible)
      libraries which we may install.
      
      For GHC 7.8 and earlier, we follow the reserved namespace
      convention as per #3017.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      18fcd9c1
  13. 08 Jan, 2016 1 commit
    • Edward Z. Yang's avatar
      Remove same-package import lists, fixes #2835. · 639cd007
      Edward Z. Yang authored
      
      
      Instead of qualifying, in some cases I just added an extra
      'hiding' pragma to squelch errors.  Common conflicts
      (just grep for hiding):
      
          - Flag
              - Distribution.Simple.Compiler
              - Distribution.PackageDescription
              - Distribution.Simple.Setup
          - installedComponentId
              - Distribution.Package
              - Distribution.InstalledPackageInfo
          - doesFileExist
              - Distribution.PackageDescription.Check
          - instantiatedWith
              - I renamed the field in InstalledPackageInfo.  But
                it's probably going away with Backpack bits; I
                migth just excise it soon.
          - absoluteInstallDirs and substPathTemplate
              - Distribution.Simple.InstallDirs
              - Distribution.Simple.LocalBuildInfo
      
      I fixed some shadowing errors by renaming local variables in some cases.
      Common shadowings (we should perhaps consider not using these as
      method/field names):
      
          - freeVars
          - components
          - noVersion
          - verbosity
          - get
          - description
          - name
      
      Some data structures were moved around (IPIConvert and ABIHash)
      to make it easier to handle import lists.
      
      Some functions in Utils could be turned into reexports of standard
      library functions.
      
      No explicit imports were removed from non-Cabal imports.  These
      imports help maintain warning cleanliness across versions of GHC,
      so I don't recommend removing them.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      639cd007
  14. 23 Dec, 2015 2 commits
  15. 16 Dec, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Make Distribution.Simple.Configure warning-free & CPP-free · 4e33454f
      Herbert Valerio Riedel authored
      GHC 8.0 changed the `ErrorCall` type to have an extended constructor,
      and backward compatibility has been provided via PatternSynonyms:
      
          data ErrorCall = ErrorCallWithLocation String String
              deriving (Eq, Ord)
      
          pattern ErrorCall :: String -> ErrorCall
          pattern ErrorCall err <- ErrorCallWithLocation err _ where
                  ErrorCall err  = ErrorCallWithLocation err ""
      
      However, due to https://ghc.haskell.org/ticket/8779 the
      exhaustive-checker doesn't cope well with pattern-synonyms yet, and so
      we get a non-exhaustive pattern-match failure when matching on
      'ErrorCall' now.
      
      As the matching on the constructor 'ErrorCall' is done here to help
      infer the Exception instance, we can also just annotate the type
      directly, and eschew the problematic pattern match.
      
      While at it, this commit also makes this module CPP-free.
      4e33454f
    • Duncan Coutts's avatar
      Add new getInstalledPackagesMonitorFiles · 7e409fcb
      Duncan Coutts authored
      It provides a way to find out what files need to be monitored to detect
      changes in a compiler's package database.
      
      This is not used within the Cabal lib.
      7e409fcb
  16. 09 Oct, 2015 2 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Implement ComponentId, replacing PackageKey and InstalledPackageId. · b083151f
      Edward Z. Yang authored
      
      
      Today in Cabal, when you build and install a package, it is
      uniquely identified using an InstalledPackageId which is computed
      using the ABI hash of the library that was installed.  There
      are few problems with doing it this way:
      
          - In a Nix-like world, we should instead uniquely identify
            build products by some sort of hash on the inputs to the
            compilation (source files, dependencies, flags).  The ABI
            hash doesn't capture any of this!
      
          - An InstalledPackageId suggests that we can uniquely identify
            build products by hashing the source and dependencies of
            a package as a whole.  But Cabal packages contain many components:
            a library, test suite, executables, etc.  Currently, when
            we say InstalledPackageId, we are really just talking about
            the dependencies of the library; however, this is unacceptable
            if a Cabal package can install multiple libraries; we need
            different identifiers for each.
      
          - We've also needed to compute another ID, which we've called
            the "package key", which is to be used for linker symbols
            and type equality GHC-side.  It is confusing what the distinction
            between this ID and InstalledPackageIds are; the main reason
            we needed another ID was because the package key was needed
            prior to compilation, whereas the ABI hash was only available
            afterwards.
      
      This patch replaces InstalledPackageId and PackageKey with a
      new identifier called ComponentId, which has the following
      properties:
      
          - It is computed per-component, and consists of a package
            name, package version, hash of the ComponentIds
            of the dependencies it is built against, and the name
            of the component.  For example, "foo-0.1-abcdef" continues
            to identify the library of package foo-0.1, but
            "foo-0.1-123455-foo.exe" would identify the executable,
            and "foo-0.1-abcdef-bar" would identify a private sub-library
            named bar.
      
          - It is passed to GHC to be used for linker symbols and
            type equality.  So as far as GHC is concerned, this is
            the end-all be-all identifier.
      
          - Cabal the library has a simple, default routine for computing
            a ComponentId which DOES NOT hash source code;
            in a later patch Duncan is working on, cabal-install can
            specify a more detailed ComponentId for a package
            to be built with.
      
      Here are some knock-on effects:
      
          - 'id' is a ComponentId
      
          - 'depends' is now a list of ComponentIds
      
          - New 'abi' field to record what the ABI of a unit is (as it is no longer
            computed by looking at the output of ghc --abi-hash).
      
          - The 'HasInstalledPackageId' typeclass is renamed to
            'HasComponentId'.
      
          - GHC 7.10 has explicit compatibility handling with
            a 'compatPackageKey' (an 'ComponentId') which is
            in a compatible format.  The value of this is read out
            from the 'key' field.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b083151f
  17. 28 Aug, 2015 1 commit
  18. 21 Jul, 2015 1 commit
    • Edward Z. Yang's avatar
      Refactor Cabal around the idea of "library names". · f47732a5
      Edward Z. Yang authored
      
      
      In GHC 7.10, Cabal always generate package keys, including in
      cases where Backpack was involved (e.g. --instantiated-with).
      In fact, in these case, GHC needs to be able to generate the
      package key (because it will often make a substitution on the
      instantiation, and needs to know if this identity coincides with
      anything else we've seen previously).
      
      Thus, we introduce a new notion, the 'LibraryName', which
      is JUST the non-Backpack portion of a package key.  For ordinary
      packages that are definite, a 'LibraryName' is simply
      the 'PackageId' plus 'PackageKey'; for indefinite Backpack packages,
      when a package gets instantiatied, it may end up with different
      'PackageKey's even though the 'LibraryName' stays the same.
      'LibraryName's can be computed purely by Cabal.
      
      This patch:
      
          - Defines library name, which are the source package ID plus
            a hash of all the source package ID and the library names of external,
            textual dependencies,
      
          - Redefines the package key to be JUST the hash portion of a
            library name, in the case that Backpack is not used,
      
          - Records the library name in InstalledPackageInfo.
      
      Note: the source package ID is included both externally (so the library
      name is a useful handle to refer to package) and internally (so the
      hash can stand alone as the package key.)
      
      A major refactoring which is part of this commit is moving package keys/library
      names from LocalBuildInfo to LibComponentBuildInfo.  If you have an LBI, you can
      still extract a package key/library name using the new
      localPackageKey/localLibraryName function (which looks through the
      ComponentBuildInfos of a LocalBuildInfo for the library in question).  This is
      conceptually cleaner for two reasons:
      
          1. Only dependencies of the *library* are counted as part
          of the library name, as opposed to *all* dependencies which
          we previously used.
      
          2. A library name doesn't really mean much for an executable,
          or a test suite, since no one else will have to link against
          them.  So we can fall back on something simpler.
      
      A more minor refactoring is the 'LibraryName' type, which was
      previously defined by LocalBuildInfo and generally looked something
      like "HSprocess-0.1-XXXX".  We change the meaning of 'LibraryName'
      to be "process-0.1-XXXX" (thus we have to insert some HS additions
      in the code) and eliminate componentLibraries, thus assuming that
      there is only ONE Haskell library (which was the case.)  So
      we remove a little bit of generality and in return get code
      that is much easier to read.  (The only downside is GHC's hack
      to split DLLs into multiples has to be adjusted slightly, but
      this is not a big price to pay.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      f47732a5
  19. 06 Jul, 2015 1 commit
    • Duncan Coutts's avatar
      Make the profiling detail level configurable with a flag · 5a6699ef
      Duncan Coutts authored
      New flags: --profiling-detail and --library-profiling-detail.
      When profiling is enabled (by the existing flags) then these flags
      are taken into account to set the profiling detail level.
      
      The levels are:
       none
       default
       exported-functions
       toplevel-functions
       all-functions
      
      The default value for ghc for libraries is exported-functions and
      for exes is toplevel-functions.
      
      On GHC these levels correspond to the -fprof-auto* flags. The
      ghc-prof-options will override this (just because it's passed to
      ghc at the end).
      5a6699ef
  20. 27 Jun, 2015 1 commit
    • ttuegel's avatar
      Get 'builddir' from cabal.config or CABAL_BUILDDIR · 2b3282fc
      ttuegel authored
      Fixes #2484. The 'builddir' option may now be specified in cabal.config
      as well. It will also be read from the CABAL_BUILDDIR environment
      variable, if set. The order of precedence (highest to lowest) is:
      1. --builddir command line option
      2. CABAL_BUILDDIR environment variable
      3. cabal.config setting
      2b3282fc
  21. 31 May, 2015 1 commit
  22. 06 Mar, 2015 2 commits
  23. 19 Jan, 2015 1 commit