This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 06 Sep, 2016 2 commits
  2. 20 Aug, 2016 1 commit
  3. 12 Apr, 2016 3 commits
  4. 08 Apr, 2016 2 commits
  5. 01 Apr, 2016 2 commits
    • Edward Z. Yang's avatar
      Fix build-tools ordering regression (#3257, #1541) · e3a3b01b
      Edward Z. Yang authored
      
      
      When converting the component graph to operate in terms of UnitIds
      instead of CNames I accidentally introduced a regression where we
      stopped respecting build-tools when determining an ordering to
      build things.  This commit fixes the regression (though perhaps
      not in the most clean/performant way you could manage it.)  It
      also fixes a latent bug if internal libraries aren't processed
      in the correct order.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e3a3b01b
    • Edward Z. Yang's avatar
      Testing with GHC 7.0 and 7.2. · 2d388c06
      Edward Z. Yang authored
      
      
      In the process, I refactored the test suite a bit to be more robust
      and handle the --with-compiler more correctly in most cases.
      
      One note: I turned off the HPC tests with the GHC and WITH_GHC
      parameters don't match.  In principle this should work but there
      is some sort of bug.  I don't plan on fixing the bug.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2d388c06
  6. 29 Mar, 2016 3 commits
  7. 22 Feb, 2016 2 commits
  8. 15 Feb, 2016 1 commit
  9. 14 Feb, 2016 1 commit
  10. 08 Feb, 2016 1 commit
  11. 16 Jan, 2016 1 commit
    • 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. 29 Dec, 2015 1 commit
  13. 28 Dec, 2015 1 commit
    • Edward Z. Yang's avatar
      Rewrite the package test suite. · e94552e8
      Edward Z. Yang authored
      
      
      I've rewritten the test suite to be more concise and "correct by
      construction".  The primary method that this is achieved by
      is introducing the 'TestM' monad, which carries around the
      important state for the tests so that (1) we don't have to
      pass it as an argument all around, and (2) we can automatically
      make the correct decisions about how to do things.  This new
      method emphasises "configuration by convention": we assume
      that a test-case named "Foo" has its test packages in the
      directory "tests/PackageTests/Foo".
      
      A secondary change is that all command functions automatically fail if
      they have a non-zero exit code (unless you use the 'shouldFail'
      combinator which inverts the sense.)  This saves a lot of typing
      on test-cases.  (In fact, I've reorganized all of the commands
      related here.)
      
      In the process, I've tightened up the logic for how to find the
      LocalBuildInfo of the Cabal we've testing, so we should now
      reliably be testing the inplace Cabal library, and not the
      system library (as was often the case.)
      
      Because things are a lot shorter, there is no good reason to
      make Check modules except for the biggest test cases.  Most
      test-cases have been folded into PackageTests.Tests; if you
      have a small test-case you should just put it there.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e94552e8
  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. 26 Sep, 2015 1 commit
    • enolan's avatar
      Carry package dbs into testsuite · bc3e1a7d
      enolan authored
      Prior to this patch, the testsuite used your global package db, and
      sometimes, the inplace package db, which led to errors if you didn't
      have old-time installed globally. They looked like this:
      
      BuildDeps/SameDepsAllRound:          Cabal result was Result {successful = False, success = Failure, outputText = "\"/home/enolan/cabal/Cabal/tests/Setup configure --user -w  /home/enolan/.nix-profile/bin/ghc\" in PackageTests/BuildDeps/SameDepsAllRound\nConfiguring SameDepsAllRound-0.1...\nSetup: At least the following dependencies are missing:\nold-time -any\n"}
      bc3e1a7d
  16. 08 Aug, 2015 1 commit
  17. 29 Jun, 2015 1 commit
  18. 20 Mar, 2015 1 commit
  19. 17 Mar, 2015 1 commit
  20. 18 Dec, 2014 1 commit
    • ttuegel's avatar
      PackageTests: set dist prefix · 61f97e07
      ttuegel authored
      Some package tests run multiple tests on the same package, causing the
      build directory to be overwritten. For debugging, it is important to
      keep the build directory contents, so in this case we run each test
      with a different build directory.
      61f97e07
  21. 14 Sep, 2014 1 commit
  22. 15 May, 2014 1 commit
  23. 10 May, 2014 1 commit
  24. 31 Aug, 2013 1 commit
  25. 30 Aug, 2013 1 commit
  26. 27 Aug, 2013 1 commit
    • tibbe's avatar
      Unit tests: use configure GHC · 323460ec
      tibbe authored
      This means that the package tests will pick up whatever GHC was passed
      on the
      
          cabal configure --enable-tests -w some-ghc
      
      command line.
      323460ec
  27. 23 Jul, 2013 1 commit
  28. 10 Dec, 2012 1 commit
    • Duncan Coutts's avatar
      Support for C/C++/Obj-C as main · de88f409
      Duncan Coutts authored
      This allows specifying the main-is field as a C file.
      
      This is closely based on patches by Edward Z. Yang, who in turn credits
      and earlier set of patches by Irene Knapp. The slight difference in
      this version of the patch is that it is adjusted to work with the new
      approach where we have separate hs compile; c compile; and link phases.
      de88f409
  29. 31 Oct, 2012 3 commits
  30. 30 Oct, 2012 1 commit