This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 18 Mar, 2015 1 commit
  2. 06 Mar, 2015 1 commit
  3. 28 Jan, 2015 1 commit
    • ttuegel's avatar
      rollback API changes about --enable-profiling · 25f7f9a1
      ttuegel authored
      Now the released version of cabal-install can be built against
      Cabal-1.22.1.0, and there is no need to modify the upper bound on
      Hackage. This change prevents Cabal-1.22.1.0 from emitting deprecation
      warnings about --enable-executable-profiling, but the correct behavior
      of --enable-profiling is preserved. There is no need to rollback the API
      changes on master; cabal-install already requires Cabal to have the same
      major version.
      25f7f9a1
  4. 18 Jan, 2015 2 commits
  5. 11 Jan, 2015 1 commit
    • ttuegel's avatar
      D.Compat.Binary: backport binary generics to binary-0.5 · f2a07d2c
      ttuegel authored
      GHC generics are used to derive binary instances for types appearing
      in the persistent build config, which requires GHC >= 7.2 and
      binary >= 0.7. Unfortunately, GHC < 7.8 ships with binary == 0.5.*.
      The missing module is Data.Binary.Generics, which we have copied from
      binary-0.7.2.3 to Distribution.Compat.Binary.Generics. To provide
      generic implementations for the Binary class, we also have to provide
      our own implementation, which is copied from binary-0.7.2.3 to
      Distribution.Compat.Binary.Class. The interface required by Cabal is
      exported from Distribution.Compat.Binary. This is only done if
      bootstrapping Cabal with GHC < 7.8 or if binary >= 0.7 is not available,
      otherwise Distribution.Compat.Binary simply re-exports Data.Binary.
      
      (cherry picked from commit c650e347)
      f2a07d2c
  6. 03 Jan, 2015 1 commit
    • tibbe's avatar
      Add support for emitting debug info · fbf84997
      tibbe authored
      If the compiler (e.g. GHC 7.10) supports outputting OS native debug
      info (e.g. DWARF) passing --enable-debug-info[=n] to cabal will
      instruct it to do so.
      fbf84997
  7. 18 Dec, 2014 4 commits
    • ttuegel's avatar
      Enable library profiling when profiling executables · 6b631745
      ttuegel authored
      It doesn't make any sense to do a profiling build of an executable if
      the library doesn't have a profiled build! The option
      --enable-executable-profiling is changed to --enable-profiling to
      reflect that it is now a global flag. The old option is still recognized
      (for now).
      6b631745
    • ttuegel's avatar
      Build shared library when linking executables dynamically · 2976fef4
      ttuegel authored
      Dynamically linking executables will fail without a shared library
      unless the executables do not depend on the library or there is no
      library. If there is no library, building shared libraries comes at no
      cost. If there is a library, the executables usually depend on it, so it
      makes sense to --enable-shared.
      
      If the user passes --disable-shared, it will still be honored, but a
      warning will be produced.
      2976fef4
    • Luite Stegeman's avatar
      f5e713d7
    • Luite Stegeman's avatar
      Read `setup-config' into a strict ByteString, making sure that the · f958e32e
      Luite Stegeman authored
      file handle does not stay open.
      
      This caused permission denied problems on MSYS where the working
      temp directory could not be removed after building a package because
      of a lingering open file.
      
      Additionally, I've uglified the qualifier for the import of
      Data.ByteString.Lazy.Char8, since it's ugly and potentially risky,
      and should be clearly visible as such.
      f958e32e
  8. 16 Dec, 2014 1 commit
  9. 12 Dec, 2014 6 commits
  10. 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
  11. 09 Dec, 2014 1 commit
    • ttuegel's avatar
      getConfigStateFile: throw meaningful exceptions, recover old LBI · 78776496
      ttuegel authored
      getConfigStateFile now throws meaningful exceptions which are caught by
      tryGetConfigStateFile and friends, which are allowed to propagate,
      rather than just calling 'die'. If the LocalBuildInfo was generated by
      an older version of Cabal, an exception is still generated, but the
      LocalBuildInfo is included if it is recoverable. This feature is used to
      reduce code duplication between the library and the test suite.
      78776496
  12. 08 Dec, 2014 1 commit
  13. 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
  14. 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
  15. 29 Oct, 2014 1 commit
  16. 19 Oct, 2014 2 commits
  17. 22 Sep, 2014 1 commit
  18. 18 Sep, 2014 1 commit
  19. 14 Sep, 2014 3 commits
  20. 30 Aug, 2014 1 commit
  21. 29 Aug, 2014 1 commit
  22. 28 Aug, 2014 1 commit
  23. 27 Aug, 2014 2 commits
    • Edward Z. Yang's avatar
      Make Distribution.Simple.PackageIndex polymorphic in package storage. · 4e8c6ecc
      Edward Z. Yang authored
      
      
      BC note: renamed type PackageIndex :: * to InstalledPackageIndex.
      
      The intent is to have cabal-install use this package index in order to
      track information about compilation in progress.  We introduce a new
      PackageInstalled type-class to keep track of data types which have their
      IDs and dependency graphs in InstalledPackageId.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      4e8c6ecc
    • 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
  24. 04 Aug, 2014 2 commits
    • Edward Z. Yang's avatar
      Add $pkgkey template variable, and use it for install paths. · 1d33c8f5
      Edward Z. Yang authored
      
      
      At the moment, $pkgkey is not supported for build reports, although in
      principle we could add support for it, assuming that the configure step
      succeeds.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      1d33c8f5
    • Edward Z. Yang's avatar
      Implement package keys, distinguishing packages built with different deps/flags · 41610a0b
      Edward Z. Yang authored
      
      
      Previously, the GHC ecosystem assumed that for any package ID (foo-0.1), there
      would only be one instance of it in the installed packages database.  This
      posed problems for situations where you want a package compiled twice against
      different sets of dependencies: they could not both exist in the package
      database.
      
      Package keys are a hash of the package ID and package
      dependencies, which identify a package more uniquely than a package ID, but less
      uniquely than an installed package ID. Unlike installed package IDs, these can
      be computed immediately after dependency resolution, rather than after
      compilation.  Package keys require support from the compiler.  At the moment,
      only GHC 7.10 supports package keys (the reason is that old versions of GHC
      do a sannity check to see that the <pkg-name>-<pkg-version> stored in the
      package database matches with the -package-name embedded in an hi file; so
      the format is fixed.) We fallback to package keys == package IDs for old
      versions.
      
      Note: the ./Setup configure fallback script does not try particularly hard to
      pick consistent sets of dependencies.  If your package database is too difficult
      for it to resolve, manually provide installed package IDs or use cabal-install's
      dependency solver.
      
      Note: This patch *suspends* the reinstall check unless it would result in
      a different package, so cabal-install will now happily reinstall foo-0.1
      compiled against bar-0.2 if foo-0.1 already exists.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      41610a0b
  25. 17 Jul, 2014 1 commit
  26. 16 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Implement "reexported-modules" field, towards fixing GHC bug #8407. · 62450f9a
      Edward Z. Yang authored
      
      
      Re-exported modules allow packages to reexport modules from their
      dependencies without having to create stub files.  Reexports of the same
      original module don't count as ambiguous imports when module finding
      occurs.  The syntax is:
      
          "orig-pkg" OrigName as NewName
      
      You can omit 'as NewName', in which case it is reexported as the same
      name.  Self referential aliases work too; however, they're only visible
      to packages which depend on this package.
      
      Left to future work: just provide a module name 'OrigName', where ghc-pkg
      figures out what the source package is.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      62450f9a