This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 03 Jan, 2016 1 commit
  2. 29 Dec, 2015 2 commits
  3. 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
  4. 23 Dec, 2015 1 commit
  5. 07 Nov, 2015 1 commit
    • Joachim Breitner's avatar
      test: New mode --show-details=direct · 2542325e
      Joachim Breitner authored
      This mode implements #2911, and allows to connect the test runner
      directly to stdout/stdin. This is more reliable in the presence of no
      threading, i.e. a work-arond for #2398.
      
      I make the test suite use this, so that it passes again, despite
      printing lots of stuff. Once #2398 is fixed properly, the test suite
      should probably be extended to test all the various --show-details
      modes.
      2542325e
  6. 05 Nov, 2015 2 commits
  7. 11 Oct, 2015 1 commit
  8. 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
  9. 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
  10. 20 Aug, 2015 1 commit
    • Thomas Miedema's avatar
      Don't check metadata of installed .a file · e18ad75a
      Thomas Miedema authored
      When running the `strip` command (without the -D option) on an installed
      .a file, `strip` will write the current time to all file headers in the
      .a file. Update the DeterministicAr test to allow this.
      
      The DeterministicAr test is supposed to test for regressions in
      relinking avoidance. It is sufficient to do so in the build directory
      only.
      e18ad75a
  11. 08 Aug, 2015 4 commits
  12. 25 Jul, 2015 1 commit
  13. 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
  14. 29 Jun, 2015 1 commit
  15. 06 Jun, 2015 1 commit
  16. 04 Jun, 2015 3 commits
  17. 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
  18. 26 Mar, 2015 1 commit
  19. 20 Mar, 2015 1 commit
  20. 17 Mar, 2015 3 commits
  21. 15 Mar, 2015 1 commit
    • ttuegel's avatar
      fix HPC tests with GHC 7.10 · 1bda4281
      ttuegel authored
      Starting with version 7.10, GHC puts the module interface (.mix) files
      for each project in a subdirectory of -hpcdir named for the package
      key. We must adjust the search path accordingly when checking for the
      .mix file.
      1bda4281
  22. 06 Mar, 2015 1 commit
  23. 11 Jan, 2015 1 commit
  24. 04 Jan, 2015 1 commit
  25. 19 Dec, 2014 1 commit
  26. 18 Dec, 2014 4 commits
    • 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
    • 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
    • ttuegel's avatar
      PackageTests: add full range of TestSuite/Hpc tests · 6af70b39
      ttuegel authored
      Also runs the HPC tests regardless of the detected version.
      6af70b39
  27. 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
  28. 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