This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 12 Apr, 2016 1 commit
  2. 08 Apr, 2016 1 commit
  3. 31 Mar, 2016 1 commit
  4. 29 Mar, 2016 7 commits
    • Edward Z. Yang's avatar
      40d6f0af
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • 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
  5. 20 Feb, 2016 1 commit
  6. 30 Jan, 2016 1 commit
  7. 25 Jan, 2016 1 commit
  8. 16 Jan, 2016 2 commits
    • 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
  9. 10 Jan, 2016 1 commit
    • 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
  10. 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
  11. 23 Dec, 2015 1 commit
  12. 16 Dec, 2015 4 commits
    • Duncan Coutts's avatar
      Add mutli-instance support to registerPackage · 2d0a8781
      Duncan Coutts authored
      With support for GHC and GHCJS. All Cabal lib internal uses remain
      traditional single instance, so there's no change of behaviour.
      2d0a8781
    • Duncan Coutts's avatar
      Use the new package db utils to simplify createInternalPackageDB · e86851d7
      Duncan Coutts authored
      And fix up the db path for UHC. UHC cannot just register anywhere, like
      compilers that have a hc-pkg can. It has to be special locations. Now
      that registerPackage no longer takes the inplace :: Bool arg, UHC's impl
      of registerPackage has to get the dir from the PackageDbStack without
      knowing if it's implace or not. So the correct inplace location has to
      be set earlier for the inplace package db, which is what this does.
      e86851d7
    • Duncan Coutts's avatar
      Extend HcPkg.init support for dir-style package dbs · 12b222af
      Duncan Coutts authored
      The HcPkgInfo useSingleFileDb is split into two: supportsDirDbs and
      requiresDirDbs. Then rather than HcPkg.init callers having to do the
      writeFile [] thing, HcPkg.init does it itself automatically based on the
      HcPkgInfo. In the case that supportsDirDbs is True but requiresDirDbs is
      False then we have a choice, to use dir style or file style. For
      compatability reasons, when using ghc/ghc-pkg for the inplace package db
      we want to use the old file style, even though dir style is supported.
      However in other circumstances (e.g. in places in cabal-install) we
      would like to use the dir style if it's supported, and there are no
      backwards compat issues. So HcPkg.init gains a new Bool arg to request
      using the file style if it's still supported. Only this mode is used
      within Cabal itself, but the non-compat mode is available for other
      users.
      
      The compiler-independent initPackageDB is left with the same old
      behaviour, but a new createPackageDB has the extra compat argument
      (which is only passed to hc-pkg for ghc-pkg).
      12b222af
    • Duncan Coutts's avatar
      Change regiserPackage to not require so much info · dee7e0a5
      Duncan Coutts authored
      Drop the now-unused PackageDescription and inplace :: Bool args. And
      instead of taking the whole LocalBuildInfo, just take the bits we need:
      the compiler and program db. The package db stack was already passed in
      separately. Also reorder args to follow standard conventions.
      dee7e0a5
  13. 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
  14. 17 Aug, 2015 1 commit
  15. 16 Aug, 2015 1 commit
  16. 25 Jul, 2015 1 commit
  17. 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
  18. 04 Jul, 2015 1 commit
    • kristenk's avatar
      Support pure test packages (issue #1186) · f2f4ad4b
      kristenk authored
      This commit relaxes D.PackageDescription.Check.checkConfiguredPackage so that it
      only warns when a package declares no executables, libraries, tests, or
      benchmarks.  Similarly, it relaxes the check during build to only require one
      component that is buildable and enabled.  Install now requires an executable or
      library.
      f2f4ad4b
  19. 29 Mar, 2015 1 commit
    • Ian Ross's avatar
      Allow preprocessors to specify extra C sources · a30b11fe
      Ian Ross authored
      Add functionality to allow preprocessors like hsc2hs and C2HS to inform
      Cabal of extra C sources that they create that need to be compiled and
      linked.  Includes hsc2hs-based test case.
      a30b11fe
  20. 18 Mar, 2015 1 commit
    • ttuegel's avatar
      Fix test interface detailed-0.9 with GHC 7.10 · ba4b078d
      ttuegel authored
      Fixes #2476. Cabal could not build detailed-0.9 test suites with GHC
      7.10 because the wrong package key was being used to build the test
      suite library.
      
      TODO: We should add real multi-library support to Cabal!
      ba4b078d
  21. 27 Jan, 2015 1 commit
  22. 05 Jan, 2015 1 commit
  23. 18 Dec, 2014 1 commit
  24. 26 Nov, 2014 1 commit
    • Edward Z. Yang's avatar
      Preliminary support for compiling signature files, using --instantiate-with. · 0ef39071
      Edward Z. Yang authored
      
      
      There's no chrome here, but some of the guts for Cabal supporting compiling
      signatures.  The key UI is a new --instantiate-with flag for ./Setup (no support
      cabal-install side!) which properly modifies the package key, calculates extra
      hole dependencies for a package, and ensures an appropriately
      translated -sig-of is passed to GHC.  The UI here is supremely user-unfriendly:
      the intent is that users will use cabal-install to calculate these parameters
      for them.
      
      ToDo: Cabal's inconsistency check in ./Setup needs to be adjusted to be
      less zealous.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      0ef39071
  25. 04 Nov, 2014 1 commit
    • Edward Z. Yang's avatar
      Consolidate exposed-modules and reexported-modules in InstalledPackageInfo. · 1f8a0a20
      Edward Z. Yang authored
      
      
      A note first: this patch does NOT modify the user-facing experience in Cabal
      files; it only changes how we register information in the installed package
      database.
      
      This patch takes the exposed-modules and reexported-modules fields in
      the InstalledPackageInfo structure and consolidates them into just the
      exposed module fields, which now has a Maybe flag indicating if a
      module is reexported and, if it is, what the original module was.  I've
      also added in a field for signatures although it is currently unused.
      
      The big benefit of this change is that it will make processing at the GHC level
      much more uniform when we add signatures: signatures can also be reexported
      and the new representation means we can share the code.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      1f8a0a20
  26. 19 Oct, 2014 1 commit
  27. 18 Sep, 2014 1 commit
  28. 27 Aug, 2014 2 commits
    • Duncan Coutts's avatar
      Change rep of module re-exports, and do resolution ourselves · a3d3273a
      Duncan Coutts authored
      The initial support for module re-exports relied on ghc-pkg to resolve
      user-specified re-exports to references to specific installed packages.
      This resolution is something that can fail so it's better for Cabal to
      do it during the package configure phase.
      
      In addition, it is inconvenient in ghc-pkg to be doing this resolution,
      and it just seems fishy as a design. Also, the same ModuleExport type
      was being used both for user-specified source re-exports and also for
      the specific re-exports in the package db.
      
      This patch splits the type into two: one for source level, and one for
      resolved ones for use in the package db. The configure phase resolves
      one to the other.
      
      One minor change: it is now possible to re-export a module defined in
      the same package that is not itself exported (ie it's in other-modules,
      rather than exposed-modules). Previously for modules definied in the
      same package they had to be themselves exported. Of course for
      re-exports from other packages they have to be exposed.
      a3d3273a
    • Edward Z. Yang's avatar
      Change the inplace package database to not use file-style database. · 8d59dc9f
      Edward Z. Yang authored
      
      
      Instead we use HcPkg.init (e.g. ghc-pkg init). For ghc-pkg this will
      create a new directory style db.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      Signed-off-by: Duncan Coutts's avatarDuncan Coutts <duncan@well-typed.com>
      8d59dc9f
  29. 04 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Fix regression for V09 test library handling. · 2b50d0a7
      Edward Z. Yang authored
      
      
      detailed-1.0 test libraries allow users to define a test library as part
      of package, which has a different package ID than the original library.
      When I made the change to packageKey, I forgot to assign new package keys
      here; the result was that the test library was compiled with the same
      package key as the original.  The fix is a bit of a hack, since arguably
      this should have been done properly in the configure step!
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2b50d0a7