This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 04 Aug, 2014 1 commit
    • 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
  2. 14 Apr, 2014 1 commit
  3. 02 Feb, 2014 1 commit
  4. 19 Dec, 2013 1 commit
  5. 23 Aug, 2013 1 commit
  6. 21 Mar, 2013 1 commit
  7. 12 Mar, 2013 1 commit
  8. 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
  9. 26 Nov, 2012 2 commits
  10. 27 Mar, 2012 1 commit
  11. 16 Nov, 2011 1 commit
  12. 23 Oct, 2011 1 commit
  13. 12 Oct, 2011 1 commit
    • tibbe's avatar
      Build executable benchmarks · e702bfd2
      tibbe authored
      Benchmarks are treated just like test suites in that a dummy
      Executable is created and built.
      e702bfd2
  14. 11 Oct, 2011 1 commit
  15. 18 Jul, 2011 1 commit
  16. 08 Jul, 2011 1 commit
    • Duncan Coutts's avatar
      Fix withComponentsLBI and move Components to LocalBuildInfo module · 1c20a632
      Duncan Coutts authored
      An annoyance of the current Simple build system is that each phase
      (build, install, etc) can be passed additional HookedBuildInfo which
      gets merged into the PackageDescription. This means that we cannot
      process the PackageDescription up front at configure time and just
      store and reuse it later, we have to work from it each time afresh.
      
      The recent addition of Components (libs, exes, test suites) and a
      topoligical sort of the components in the LocalBuildInfo fell foul
      of this annoyance. The LocalBuildInfo stored the entire component
      which meant they were not updated with the HookedBuildInfo. This
      broke packages with custom Setup.hs scripts that took advantage of
      the HookedBuildInfo feature, including those with configure scripts.
      
      The solution is to store not the list of whole components but the
      list of component names. Then withComponentsLBI retrieves the actual
      components from the PackageDescription which thus includes the
      HookedBuildInfo.
      
      Also moved the Components into an internal module because (for the
      moment at least) it is part of the Simple build system, not part of
      the package description.
      1c20a632
  17. 19 Jun, 2011 1 commit
  18. 05 May, 2011 1 commit
    • intractable's avatar
      intrapackage-deps-and-per-component-preprocessing · 2e348126
      intractable authored
      This patch adds intrapackage dependency resolution so that components
      (libraries, exes, test suites) are build in the correct order.  This mean it's
      now possible to have, e.g., executables that depend on other executables defined
      in the same package description: the build-tools namespace has been extended
      accordingly.
        
      Related to this change is the refactoring of the do-it-all preprocessSources
      function, formerly invoked by initialBuildSteps, into a a function
      preprocessComponent that is invoked when a component is being built.  This lets
      us use executables defined in a package to be used as a custom preprocessor when
      building other components.
        
      Finally, a number of functions now operate on values of the sum type
      PackageDescription.Component rather than specifically operating on Library or
      Executable and so forth.
      2e348126
  19. 30 Jan, 2011 1 commit
  20. 11 Jan, 2011 1 commit
  21. 27 Jul, 2010 1 commit
  22. 10 Oct, 2010 1 commit
  23. 25 Aug, 2010 1 commit
    • adept's avatar
      Auto-reconfiguration when .cabal is newer than setup-config · 549a6985
      adept authored
      This patch adds "ConfigFlags" to the "LocalBuildInfo" and reuses them to
      perform "configureAction" when .cabal file is changed. This has
      the same effect as re-running "configure" with the most recent used
      set of options, which should be the sensible thing to do.
      
      Closes #294, #477, #309 and #518.
      549a6985
  24. 07 Jun, 2010 1 commit
  25. 01 Jun, 2010 1 commit
    • ttuegel's avatar
      Using more specific error messages for unsupported test types · f77f9334
      ttuegel authored
      Ticket #215 (Overhaul support for packages' tests). Replaced generic error
      message about unsupported test types with specific error messages for each
      stage of the build/test process. This required changing the type of 'withTest'
      to better match 'withExe' and 'withLib'.
      f77f9334
  26. 26 May, 2010 1 commit
    • ttuegel's avatar
      Configure and build executable testsuites · d16062cc
      ttuegel authored
      Ticket #215 (Overhaul support for packages' test). During the
      build stage, executable testsuites are handled analogously to
      ordinary executables. This means their sources are
      preprocessed and compiled. To actually compile, the build
      stage actions are performed on a dummy Executable.
      d16062cc
  27. 20 Mar, 2010 1 commit
    • Duncan Coutts's avatar
      Fix local inplace registration for ghc-6.12 · 2ff64d8a
      Duncan Coutts authored
      This is for the case of intra-package deps where the lib has to be
      registered into a local package db. We use "-inplace" suffix for
      the local installed package ids (rather than using an ABI hash).
      2ff64d8a
  28. 28 Dec, 2009 1 commit
  29. 05 Oct, 2009 2 commits
    • Duncan Coutts's avatar
      Stop converting between installed package id and source package id · 7f9ad6bc
      Duncan Coutts authored
      In the LocalBuildInfo, for each component, for the list of component
      dependencies, keep both the InstalledPackageId and the PackageId.
      That way we don't need to keep converting the InstalledPackageId
      to the PackageId, via the package index (which is just horrible).
      7f9ad6bc
    • Duncan Coutts's avatar
      Rewrite the PackageIndex again · 15f70a85
      Duncan Coutts authored
      It's a unified index again, rather than one for looking up by an
      InstalledPackageId and one for the source PackageId. The new one
      lets you look up by either. It also maintains the order of
      preference of different installed packages that share the same
      source PackageId. In configure we just pick the first preference.
      15f70a85
  30. 22 Aug, 2009 1 commit
  31. 06 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Add a unuque identifier for installed packages (part 4 of 9) · 443e099b
      Simon Marlow authored
      Distribution.Simple.LocalBuildInfo: 
      
        - the LocalBuildInfo record contains an index of the installed
          packages; this has changed from PackageIndex InstalledPackageInfo
          to InstalledPackageIndex.
      
        - ComponentLocalBuildInfo stores the "external package dependencies"
          of the component, which was 
            componentPackageDeps :: [PackageId]
          and is now
            componentInstalledPackageDeps :: [InstalledPackageId]
      
        - we now export
            componentPackageDeps :: LocalBuildInfo -> [PackageId]
          (since to get the PackageId for an InstalledPackageId, you need
          to look it up in the InstalledPackageIndex, which is in the
          LocalBuildInfo)
      
        - similarly, previously
            externalPackageDeps :: LocalBuildInfo -> [PackageId]
          is now
            externalPackageDeps :: LocalBuildInfo -> [InstalledPackageId]
      443e099b
  32. 07 Jul, 2009 1 commit
  33. 05 Jul, 2009 1 commit
  34. 31 May, 2009 1 commit
  35. 30 May, 2009 2 commits
    • Duncan Coutts's avatar
      Improve an internal error message slightly · e0ee8942
      Duncan Coutts authored
      e0ee8942
    • Duncan Coutts's avatar
      Detect intra-package build-depends · 3600d6cb
      Duncan Coutts authored
      Based on an original patch by Stephen Blackheath
      With this change build-depends on a library within the same package
      are detected. Such deps are not full handled yet so for the moment
      they are explicitly banned, however this is another step towards
      actually supporting such dependencies. In particular deps on
      internal libs are resolved to the internal one in preference to any
      existing external version of the same lib.
      3600d6cb
  36. 28 May, 2009 1 commit
  37. 27 May, 2009 1 commit