This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 11 Jul, 2016 1 commit
  2. 19 May, 2016 1 commit
  3. 31 Mar, 2016 1 commit
  4. 29 Mar, 2016 1 commit
    • 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
  5. 05 Mar, 2016 1 commit
  6. 14 Feb, 2016 1 commit
  7. 13 Feb, 2016 1 commit
  8. 30 Jan, 2016 1 commit
  9. 25 Jan, 2016 1 commit
  10. 16 Jan, 2016 3 commits
    • Edward Z. Yang's avatar
      b713bf52
    • 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
      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
  11. 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
  12. 16 Dec, 2015 2 commits
    • Duncan Coutts's avatar
      Extend ConfiguredProgram with search locations looked at · b39b906d
      Duncan Coutts authored
      This is to allow monitoring programs for changes. The combination of the
      location where the program was found, and all the other locations where
      the program was looked for gives the full set of files to monitor for
      changes in that program.
      
      The Program programFindLocation method is extended to return the
      locations looked at but where the prog was not found. The default
      implementation of programFindLocation, findProgramOnSearchPath, is
      extended to return those locations.
      
      Other places have to change, mostly just the type. In a couple places in
      GHC & GHCJS where there is additional searching done, the not-found
      locations have to be collected and returned.
      b39b906d
    • 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
  13. 23 Nov, 2015 1 commit
  14. 01 Nov, 2015 1 commit
  15. 09 Oct, 2015 1 commit
    • 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
  16. 17 Aug, 2015 1 commit
  17. 16 Aug, 2015 1 commit
  18. 29 Jul, 2015 1 commit
  19. 27 Jul, 2015 1 commit
  20. 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
  21. 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
  22. 11 Jun, 2015 1 commit
  23. 06 Mar, 2015 1 commit
  24. 03 Jan, 2015 2 commits
  25. 18 Dec, 2014 3 commits
    • barmston's avatar
      cabal install can be used inside a cabal exec environment · 0a4aed40
      barmston authored
      Inside a cabal exec environment cabal should be configured to always use the
      correct environment. When there is a sandbox this is addressed by setting the
      CABAL_SANDBOX_CONFIG environment variable.
      
      However GHC is configured to use the correct package database through setting
      the GHC_PACKAGE_PATH environment variable to include the sandbox database. The
      Cabal library previously refused to operate when GHC_PACKAGE_PATH is set in
      order to avoid having a different view of the package databases to GHC.
      
      In the case of a cabal exec environment being loaded for a cabal sandbox, it
      is safe to allow the use of GHC_PACKAGE_PATH as it is being used to ensure
      that GHC uses the same package database as cabal does.
      
      A check is made that GHC_PACKAGE_PATH matches the value that cabal exec set it
      to. If it does use of GHC through cabal is permitted.
      
      Fixes #1800
      0a4aed40
    • Luite Stegeman's avatar
      f5e713d7
    • Luite Stegeman's avatar
      Move parts of Distribution.Simple.GHC that can be shared with other · 40ee6191
      Luite Stegeman authored
      GHC-derived compiler flavors to Distribution.Simple.GHC.Internal
      40ee6191