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 2 commits
  3. 14 Jan, 2016 3 commits
  4. 11 Jan, 2016 1 commit
  5. 10 Jan, 2016 5 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
      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. 31 Dec, 2015 1 commit
  8. 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
  9. 28 Dec, 2015 1 commit
  10. 24 Dec, 2015 1 commit
  11. 23 Dec, 2015 2 commits
  12. 22 Dec, 2015 1 commit
  13. 21 Dec, 2015 2 commits
  14. 17 Dec, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Define semigroup instances · f6428740
      Herbert Valerio Riedel authored
      This makes the code `-Wcompat`-clean with GHC 8.0
      
      Due to the amount of `Monoid` instances, a compat-layer is used
      rather than flooding the code-base with CPP conditionals.
      f6428740
    • Ben Gamari's avatar
      Program.Find: Fix on Win32 · e275a162
      Ben Gamari authored
      ee0ed0b9 added another codepath to
      Distribution.Simple.Program.Find for Win32 platforms however did not add
      correct imports or a dependency on the Win32 library. Fix this.
      e275a162
  15. 16 Dec, 2015 12 commits
    • Herbert Valerio Riedel's avatar
      Make Distribution.Simple.Configure warning-free & CPP-free · 4e33454f
      Herbert Valerio Riedel authored
      GHC 8.0 changed the `ErrorCall` type to have an extended constructor,
      and backward compatibility has been provided via PatternSynonyms:
      
          data ErrorCall = ErrorCallWithLocation String String
              deriving (Eq, Ord)
      
          pattern ErrorCall :: String -> ErrorCall
          pattern ErrorCall err <- ErrorCallWithLocation err _ where
                  ErrorCall err  = ErrorCallWithLocation err ""
      
      However, due to https://ghc.haskell.org/ticket/8779 the
      exhaustive-checker doesn't cope well with pattern-synonyms yet, and so
      we get a non-exhaustive pattern-match failure when matching on
      'ErrorCall' now.
      
      As the matching on the constructor 'ErrorCall' is done here to help
      infer the Exception instance, we can also just annotate the type
      directly, and eschew the problematic pattern match.
      
      While at it, this commit also makes this module CPP-free.
      4e33454f
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Add a few comments explaining implementation assumptions · 4164e015
      Duncan Coutts authored
      About the ghc package dbs in particular.
      4164e015
    • Duncan Coutts's avatar
      Add a comment to explain the HcPkg.recache trick · 3761cf4e
      Duncan Coutts authored
      For supporting multi instance registrations on older GHC versions.
      3761cf4e
    • Duncan Coutts's avatar
      Further CPP fix · fc1a23f8
      Duncan Coutts authored
      For some reason my cpp does not fail with #if THING_NOT_DEFINED
      but the travis one does, so use #ifdef instead.
      fc1a23f8
    • Duncan Coutts's avatar
      Fix bootstrapping CPP problem · adcfe14f
      Duncan Coutts authored
      adcfe14f
    • Duncan Coutts's avatar
      Adjust instance Binary ProgramDb to include the ProgramSearchPath · 96a010ab
      Duncan Coutts authored
      The ProgramDb Binary instance is a bit odd by leaving out the Programs,
      only including the ConfiguredPrograms. Of course this is because the
      Programs contain functions. But the ProgramSearchPath is concrete and
      should be included.
      96a010ab
    • Duncan Coutts's avatar
      Extend ConfiguredProgram with search locations looked at · b39b906d
      Duncan Coutts authored
      This is to allow monitoring programs for changes. The combination of the
      location where the program was found, and all the other locations where
      the program was looked for gives the full set of files to monitor for
      changes in that program.
      
      The Program programFindLocation method is extended to return the
      locations looked at but where the prog was not found. The default
      implementation of programFindLocation, findProgramOnSearchPath, is
      extended to return those locations.
      
      Other places have to change, mostly just the type. In a couple places in
      GHC & GHCJS where there is additional searching done, the not-found
      locations have to be collected and returned.
      b39b906d
    • Duncan Coutts's avatar
      Generalise findProgramOnSearchPath to calculate locations looked in · ee0ed0b9
      Duncan Coutts authored
      But in this patch, don't actually return them yet, so not yet changing
      the resturn type.
      
      The purpose here is change monitoring. In cabal-install we want to be
      able to automatically re-run various actions when the build environment
      changes, including when programs have changed (e.g. due to a $PATH
      change, finding the compiler in a different location). The basic
      information required for such change monitoring is not only the location
      where a program was ultimately found, but all the locations where it was
      looked for and not found. Otherwise one will miss the case where having
      previously found the program in one location, later on the program
      appears earlier in the search path. In this case a build system should
      notice and react, but if it only monitors the ultimate location where
      the program was found then this is impossible. The build system also
      needs to monitor the locations where the program was not found, to make
      sure it is still not there. This principle actually applies anytime we
      have a file search (e.g. hs-source-dirs), programs are just one example.
      ee0ed0b9
    • Duncan Coutts's avatar
      Be consistent about using findProgramOnSearchPath · 7d4fbb26
      Duncan Coutts authored
      The findProgramOnSearchPath function is what we use in most places to
      implement the Program abstraction's programFindLocation method.
      Re-export it via Program module.
      
      The only place that was still using the old findProgramLocation
      instead was in HaskellSuite. Deprecate findProgramLocation which
      is now no longer used.
      
      This is in preparation for changing the return type of
      findProgramOnSearchPath.
      7d4fbb26
    • Duncan Coutts's avatar
      Add new getInstalledPackagesMonitorFiles · 7e409fcb
      Duncan Coutts authored
      It provides a way to find out what files need to be monitored to detect
      changes in a compiler's package database.
      
      This is not used within the Cabal lib.
      7e409fcb
    • Duncan Coutts's avatar
      Export a command line unescaping utility · 3ff32fc3
      Duncan Coutts authored
      3ff32fc3