This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 16 Jan, 2016 4 commits
    • 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
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Remove instantiated-with and related support work. · 15e0e717
      Edward Z. Yang authored
      
      
      Backpack is going to have to rewrite this functionality.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      15e0e717
    • Edward Z. Yang's avatar
      94e59da8
  2. 15 Jan, 2016 3 commits
  3. 14 Jan, 2016 6 commits
  4. 11 Jan, 2016 1 commit
  5. 10 Jan, 2016 6 commits
    • Edward Z. Yang's avatar
      Remove GHCJS explicit imports. · cbc4e421
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      cbc4e421
    • Edward Z. Yang's avatar
      d1961590
    • Edward Z. Yang's avatar
      4fc9588d
    • Edward Z. Yang's avatar
      Properly assign component ID/build dir for LibV09 test libraries · 18fcd9c1
      Edward Z. Yang authored
      
      
      Cabal's LibV09 support has always been a bit skeevy.  The general
      idea was that a detailed-0.9 test-suite is built as a library
      and an Cabal-provided stub executable.  In particular, the test suite
      library must be installed to the installed package database so that the
      executable can be compiled.
      
      Old versions of Cabal did something very skeevy here:  they installed
      the test library as a "package", with the same package name as
      the "test-suite" stanza; furthermore, they built the products
      into the same directory as the library proper.
      
      Consequently, a lot of bad things could happen (both of which I've
      added tests for):
      
          1. If the name of the test suite and the name of some other
          package coincide (and have the same version), they will clobber
          each other.  In GHC 7.8 and earlier, this just flat out
          kills the build, because it will shadow.  There's an explicit
          test to make sure test suites don't conflict with the package
          name, but you can get unlucky.
      
          2. The test suite library is built into the same directory
          as the main library, which means that if the test library
          implements the same module name as something in the main
          library it will clobber the interface file and badness
          will ensue.
      
      This patchset fixes both of these issues, by (1) giving internal
      test libraries proper names which are guaranteed to be unique
      up to Cabal's dependency resolution, and (2) building the test
      suite library into a separate directory.
      
      In doing so, it also lays the groundwork for other types of
      internal libraries, e.g. #269, as well as extra (invisible)
      libraries which we may install.
      
      For GHC 7.8 and earlier, we follow the reserved namespace
      convention as per #3017.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      18fcd9c1
    • Edward Z. Yang's avatar
      Fix bootstrapping on GHC 8.0. · 98cd8ca8
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      98cd8ca8
    • Samuel Gélineau's avatar
      don't special-case versions with leading zeroes · 6b3457de
      Samuel Gélineau authored
      I could not install pcre-light because cabal failed with:
      
        parsing output of pkg-config --modversion failed
      
      The output of that command was simply "8.02", which cabal could not
      parse into a Version because of the leading zero. With this patch,
      "8.02" now parses as (Version [8,2] []).
      6b3457de
  6. 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
  7. 06 Jan, 2016 1 commit
  8. 03 Jan, 2016 2 commits
  9. 02 Jan, 2016 1 commit
  10. 31 Dec, 2015 1 commit
  11. 30 Dec, 2015 2 commits
    • randen's avatar
      Add foldl' import · 6a62d2d2
      randen authored
      -- building cabal-install in a sandbox with add-source
      on Cabal, still builds the cabal executable even though
      the Cabal build failed :-(
      6a62d2d2
    • randen's avatar
      The Cabal part for fully gcc-like response files · 0384727a
      randen authored
      * Cabal/Distribution/Simple/Haddock.hs
        * VERY IMPORTANT! this feature depends on a particular
          version of haddock, that includes the corresponding
          support for these style of response files.  However,
          we do not really know that version number!  So, this
          change here must be co-ordinated with the haddock project.
      0384727a
  12. 29 Dec, 2015 3 commits
  13. 28 Dec, 2015 4 commits
    • Edward Z. Yang's avatar
      Failing test for #3004. · 0e4d34e2
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      0e4d34e2
    • Erik de Castro Lopo's avatar
      4cd6ef0b
    • 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
    • Edward Z. Yang's avatar
  14. 24 Dec, 2015 1 commit
  15. 23 Dec, 2015 2 commits
  16. 22 Dec, 2015 1 commit
  17. 21 Dec, 2015 1 commit