This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 06 Oct, 2016 1 commit
  2. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      
      Finally, this also adds a new functor-like convenience function
      
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      
      for modifying the version number components.
      bb2026c4
  3. 22 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Update default-language & avoid default-extensions (#3880) · f87738df
      Herbert Valerio Riedel authored
      This upgrades the `default-language: Haskell98` to `Haskell2010`
      and removes `default-extensions: RankNTypes, FlexibleContexts`
      in favor of adding `LANGUAGE` pragmas where needed.
      
      Moroever, this also drops `LANGUAGE` pragmas which have become redundant
      due to `Haskell2010` (specifically, `EmptyDataDecls`,
      `ForeignFunctionInterface` and `PatternGuards`)
      
      Finally, an `other-extensions` specification is put in place for the
      `Cabal` library component.
      
      This helps loading up files directly in GHCi, such as e.g. `ghci Setup.hs`
      without having to specify `-X...` flags.
      f87738df
  4. 08 Sep, 2016 1 commit
    • Edward Z. Yang's avatar
      Provide useful call-stacks over all IO code. · 48a0d6ce
      Edward Z. Yang authored
      
      
      The key idea is that we define:
      
          type IO a = HasCallStack => Prelude.IO a
      
      and voila, call stacks are maintained across all IO!  You can
      look at the stacks using -v"debug +callstack".
      
      There are a number of IO functions for which the call stack is
      never used.  They are explicitly annotated using NoCallStackIO.
      Maybe some day they will use call stacks and we can change their
      types.  Similarly, there are a number of functions which do
      have type IO, but then suppress the redundant constraint error
      using "_ = callStack". Maybe some day we will attach call
      stacks to the exceptions we throw.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      48a0d6ce
  5. 06 Sep, 2016 5 commits
  6. 26 Jul, 2016 2 commits
  7. 23 Jul, 2016 2 commits
  8. 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
  9. 30 Jan, 2016 1 commit
  10. 25 Jan, 2016 1 commit
  11. 16 Jan, 2016 2 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
  12. 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
  13. 16 Dec, 2015 5 commits
    • 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
      Don't pass LocalBuildInfo to per-compiler registerPackage functions · b0b57da9
      Duncan Coutts authored
      Rather, pass the individual bits we need, which is the program db
      and in some cases the compiler. This is a step towards having the main
      registerPackage not take the LocalBuildInfo. That is useful in contexts
      like cabal-install where we do not have a full LocalBuildInfo, but we
      still want to be able to register packages in a compiler-agnostic way.
      b0b57da9
    • Duncan Coutts's avatar
      Change the interface to the per-compiler registerPackage functions · f1ca9680
      Duncan Coutts authored
      Remove the now-unused PackageDescription and inplace :: Bool args.
      
      Not yet changed the compiler-independent registerPackage.
      f1ca9680
    • Duncan Coutts's avatar
      UHC: registerPackage stop using source pkg and inplace args · 17af6b98
      Duncan Coutts authored
      UHC's version of registerPackage is the only one that makes use of the
      PackageDescription and inplace :: Bool args, and it's quite wrong for
      doing so. Registering a package should depend on the content of the
      InstalledPackageInfo and the PackageDBStack to register into and the
      Compiler to register with. It should not depend on the original source
      PackageDescription, and should not need a separate inplace arg. The
      location is determined by the PackageDBStack. UHC was not following
      this pattern and thereby forcing the general compiler independent
      registerPackage to take annoying and unnecessary arguments.
      
      With this patch, the register location is determined by the
      PackageDBStack. The source package id also comes from the
      InstalledPackageInfo rather than the source PackageDescription.
      
      This patch does not yet change the registerPackage type.
      17af6b98
    • Duncan Coutts's avatar
      UHC: factor out getGlobalPackageDir function · 0501e50a
      Duncan Coutts authored
      It's used three times already. This isn't important on it's own, but
      simplifies subsequent changes, when we add yet another use of it.
      0501e50a
  14. 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
  15. 10 Dec, 2014 1 commit
    • Luite Stegeman's avatar
      use CompilerInfo rather than CompilerId for resolving flags and · 7d91b773
      Luite Stegeman authored
      path templates.
      
      CompilerInfo contains more information about the compiler than
      CompilerId, which just stores the flavour and version. In particular,
      CompilerInfo knows an AbiTag, which can be used to tell binary
      incompatible results from the same compiler apart, and detailed
      information about supported languages and extensions.
      
      Some fields in CompilerInfo may be left unknown (Nothing). This can
      be used in the future to allow partially resolving configurations
      based on supported languages or extensions.
      7d91b773
  16. 27 Aug, 2014 1 commit
  17. 14 Apr, 2014 1 commit
  18. 22 Feb, 2014 1 commit
  19. 02 Feb, 2014 1 commit
  20. 07 Oct, 2013 1 commit
  21. 01 Mar, 2013 1 commit
    • lukexi's avatar
      Return Maybe Platform as part of compiler configure, and place it in... · 7a0941c8
      lukexi authored
      Return Maybe Platform as part of compiler configure, and place it in LocalBuildInfo as hostPlatform.
      GHC infers the platform form ghc --info using new 'platformFromTriple' function. Other compilers return Nothing, which triggers fallback to old behavior of using buildPlatform. hostPlatform is then threaded through to initialPathTemplateEnv.
      7a0941c8
  22. 23 Oct, 2011 1 commit
  23. 19 Jun, 2011 1 commit
  24. 26 Oct, 2010 1 commit
  25. 25 Oct, 2010 1 commit
  26. 18 Oct, 2010 3 commits
  27. 23 Sep, 2010 1 commit