This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 19 Feb, 2017 1 commit
    • Edward Z. Yang's avatar
      Refactor setupMessage use in Cabal library. · bc9d5ada
      Edward Z. Yang authored
      
      
      I noticed that I was repeatedly writing the same code
      to print out more elaborate information when we do builds,
      so I refactored it all into one place.  In the process,
      I think that I have made the build output more generally
      useful.
      
      The key changes:
      
          - There is a new function setupMessage' which takes in
            more information than the conventional setupMessage
            does, and prints a more informative message: whereas
            setupMessage will only tell you about the package
            it is being run in, setupMessage' will also tell
            you about the component and instantiation.
      
          - I applied this function to applicable sites, in some
            cases moving around messages to be closer to the place
            where an actual operation takes place.  For example,
            the 'Building' message previously only was triggered
            at the beginning of the build process; now it is
            emitted immediately before we call out to GHC.  This
            is a lot more informative, and avoids people thinking
            that we are slow because of preprocessing (we're not.)
            Something similar happened for Haddock as well.
      
      Before:
      
      Preprocessing library 'spider' for reflex-backpack-0.5.0..
      [1 of 1] Compiling Reflex.Spider.Backpack ( src/Reflex/Spider/Backpack.hs, /srv/code/reflex-backpack/dist-newstyle/build/x86_64-linux/ghc-8.1.20170123/reflex-backpack-0.5.0/c/spider/build/spider/Reflex/Spider/Backpack.o )
      
      After:
      
      Preprocessing library 'host' for reflex-backpack-0.5.0..
      Building library 'host' instantiated with
        Reflex.Host.Sig = reflex-backpack-0.5.0-inplace-spider:Reflex.Spider.Backpack
        Reflex.Sig = reflex-backpack-0.5.0-inplace-spider:Reflex.Spider.Backpack
      for reflex-backpack-0.5.0..
      [1 of 8] Compiling Reflex.Host.Sig[sig] ( host/Reflex/Host/Sig.hsig, /srv/code/reflex-backpack/dist-newstyle/build/x86_64-linux/ghc-8.1.20170123/reflex-backpack-0.5.0/c/host/reflex-backpack-0.5.0-inplace-host+FDoWUmUc0MMBtBRwItgjj9/build/reflex-backpack-0.5.0-inplace-host+FDoWUmUc0MMBtBRwItgjj9/Reflex/Host/Sig.o ) [Reflex.Basics changed]
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bc9d5ada
  2. 08 Feb, 2017 2 commits
    • Duncan Coutts's avatar
      Change Graph.fromList to fromDistinctList and fix conseqeunces · 1440ffd5
      Duncan Coutts authored
      It's really an error to try and build a graph where you have duplicate
      node keys, so remove Graph.fromList and add Graph.fromDistinctList. This
      check is always on, not just an assertion, becuase we get it for free
      given the way Maps can be constructed.
      
      All uses of Graph.fromList are ok to convert to fromDistinctList.
      1440ffd5
    • Edward Z. Yang's avatar
      Make 'Configuring component' message prettier. · 8e792524
      Edward Z. Yang authored
      
      
      Now it looks like:
      
      Configuring component lib:str-bytestring-lazy from str-bytestring-0.1.0.0
      Instantiated with:
        Data.ByteString=bytestring-0.10.8.1:Data.ByteString
        Data.ByteString.Elem=bytestring-elem-0.1.0.0-inplace:Data.ByteString.Elem
        Data.ByteString.Lazy=bytestring-0.10.8.1:Data.ByteString.Lazy
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      8e792524
  3. 23 Jan, 2017 1 commit
  4. 06 Jan, 2017 1 commit
  5. 21 Dec, 2016 1 commit
  6. 13 Dec, 2016 1 commit
  7. 26 Nov, 2016 1 commit
    • tulcod's avatar
      Implement foreign library versioning · 8744e30b
      tulcod authored
      This adds support for building foreign libraries with a given ABI version on Linux. This is enables foreign libraries to specify ABI compatibility information. This is important since ABI compatibility differs from package release versions.
      
      Two new fields are added: lib-version-info and lib-version-linux. The former accept versions Libtool-style, the latter sets SONAME versions directly. In both cases, appropriate symlinks are installed.
      
      Libtool accepts ABI version data via the -version-info flag, which takes current[:revision[:age]] data. This is then parsed into a major.minor.build version number. We copy this approach so that library versioning may be generalised to other operating systems than Linux.
      8744e30b
  8. 17 Nov, 2016 1 commit
  9. 15 Nov, 2016 1 commit
  10. 14 Nov, 2016 1 commit
  11. 13 Nov, 2016 1 commit
  12. 05 Nov, 2016 1 commit
    • Edward Z. Yang's avatar
      Add fingerprint of Generic representation when serializing. · ebcae71d
      Edward Z. Yang authored
      
      
      The idea is we can use Rep to get a full, structural representation
      of a type, and the fingerprint it using Typeable.  This gives
      us a very concise way of fingerprinting our Binary representation.
      
      This patch is not completely correct; the fingerprint needs
      to be overridable when someone writes a custom Binary instance.
      But this should be "good enough" in practice; we're not using
      these fingerprints to check anything security critical.
      
      TODO: Not sure if I have tagged all the call-sites which could
      profit from this.
      
      Fixes #4059.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      ebcae71d
  13. 01 Nov, 2016 1 commit
  14. 31 Oct, 2016 4 commits
  15. 29 Oct, 2016 1 commit
  16. 28 Oct, 2016 1 commit
    • Edsko de Vries's avatar
      Add support for foreign libraries. · 382143aa
      Edsko de Vries authored
      A stanza for a platform library looks something like
      
          platform-library test-package
            type:                native-shared
      
            if os(Windows)
              options: standalone
              mod-def-file: TestPackage.def
      
            other-modules:       MyPlatformLib.Hello
                                 MyPlatformLib.SomeBindings
            build-depends:       base >=4.7 && <4.9
            hs-source-dirs:      src
            c-sources:           csrc/MyPlatformLibWrapper.c
            default-language:    Haskell2010
      
      where native-shared means that we want to build a native shared library
      (.so on Linux, .dylib on OSX, .dll on Windows). The parser also
      recognizes native-static but this is not currently supported anywhere.
      The standalone option means that the we merge all library dependencies
      into the dynamic library (i.e., ghc options -shared -static), rather
      than make the created dynamic library just record its dependencies (ghc
      options -shared -dynamic); it is currently compulsory on Windows and
      unsupported anywhere else. The mod-def-file can be used to specify a
      module definition file, and is also Windows specific.
      
      There is a bit of refactoring in Build: gbuild is the old buildOrReplExe
      and now deals with both executables and platform libraries.
      382143aa
  17. 25 Oct, 2016 1 commit
    • Edward Z. Yang's avatar
      Drop version check when resolving package names. · af24cefe
      Edward Z. Yang authored
      
      
      In #4017, hvr reported that when he used --allow-older/--allow-newer,
      there was an assert failure in toConfiguredComponent.  Indeed
      the problem was that toConfiguredComponent was testing version
      ranges of build-depends to determine which package to select, but
      there was no satisfying one (since the build-depends field had
      not been updated.)
      
      After thinking about this for a bit, it seemed a bit bogus for
      us to be doing another version check at this late phase; we
      already picked dependencies earlier in the configuration process.
      So I decided to drop it.
      
      To drop it, however, I needed to remove support for a feature (discussed
      in #4020), which uses version ranges to disambiguate whether or not a
      dependency is on an external package or an internal package.  This
      feature doesn't seem to be very useful.  If someone asks, I'll
      check on Hackage to see if anyone is using it.
      
      Also added some useful extra debug info.
      
      Fixes #4020 and #4017
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      af24cefe
  18. 20 Oct, 2016 1 commit
    • Christiaan Baaij's avatar
      Add `--dynlibdir` · d2da6558
      Christiaan Baaij authored
      `--dynlibdir` indicates the directory in which dynamic libraries
      are installed. By default this setting is equal to:
      
      `$libdir/$abi`
      
      The static libraries will still end up in:
      
      `$libdir/$libsubdir`
      
      With `$libsubdir/$abi` as the default directory for dynamic
      libraries, dynamic libraries will by default end up in a
      single shared directory (per package database). This has the
      potential to reduce start-up times for dynamically linked
      executable as only one RPATH per package database will be
      needed.
      
      This commit uses the functionality defined in
      
      https://phabricator.haskell.org/D2611
      
      to tell GHC's > 8.0.1 package database that dynamic libraries
      are copied to the directories mentioned in the
      
      `dynamic-library-dirs`
      
      field.
      d2da6558
  19. 18 Oct, 2016 1 commit
  20. 12 Oct, 2016 1 commit
    • Bartosz Nitka's avatar
      Dedupe include dirs inherited from dependencies · 6e31b30d
      Bartosz Nitka authored
      If you build a big number of packages, all with
      the same extra -I flags, the flags get inherited
      by the dependent packages and duplicated.
      For big dependency trees it can exceed the
      maximum command line length on some systems,
      this happened to me with Linux and hoogle 5.
      
      This patch decreases the redundancy by
      dropping all but the first occurrence of
      an include dir, preserving the semantics,
      as they are processed left to right.
      6e31b30d
  21. 08 Oct, 2016 2 commits
  22. 06 Oct, 2016 5 commits
    • Edward Z. Yang's avatar
      Use the new Backpack code for the configure step · 688b31e3
      Edward Z. Yang authored
      Many of the configure functions were factored out and moved to the new
      Backpack modules. The new configure action makes a call to
      Distribution.Backpack.Configure to setup the ComponentLocalBuildInfo.
      
      Also add an @--instantiate-with@ flag to ./Setup configure, so that
      cabal-install can specify how it wants to instantiate a package that
      it is building.
      
      Also do the minimal necessary adjustments in cabal-install.
      688b31e3
    • Edward Z. Yang's avatar
      Extend ComponentLocalBuildInfo with backpack info · be1a184c
      Edward Z. Yang authored
      (1) add 'componentInstantiatedWith' to record how a component was
      instantiated (analogous to @instantiated-with@) and
      (2) fix 'componentComponentId' for the new constructors in 'Module'.
      be1a184c
    • Edward Z. Yang's avatar
      Replace the module renaming/thinning system · 1017f710
      Edward Z. Yang authored
      We had an old implementation of 'ModuleRenaming', with the
      assumption that it would be used directly in build-depends; since
      we have dropped this assumption, we can refactor 'ModuleRenaming'
      and we do so.  The main idea is to make the data type more directly
      reflect the syntax you can specify in a Cabal file; so the default
      renaming and an explicit thinning renaming are now different
      constructors.  It's no longer possible to use the "with" syntax, but
      it's not necessary either, since we have a special backpack-includes
      field to specify renamings, so we don't need them to be Monoidal.
      
      There is also a new syntax for 'hiding', which just lets you hide
      some modules when including a package. Handy!
      
      Previously, we recorded 'ModuleRenaming' in @build-depends@, but
      separated it out when we stored in 'BuildInfo'.  We now go even
      further, by changing it from a 'Map' (the only thing @build-depends@
      could support) to a list (so that a package name can be specified
      multiple times.)  This is good because now a user can instantiate
      something several times, which is useful in Backpack.
      
      Also add the new field @backpack-includes@ which can be used to exert
      fine-grained control over what modules a package brings into scope,
      include it multiple times, etc.
      
      In the .cabal checks, replace 'depsUsingThinningRenamingSyntax' with a
      more direct check to see if @backpack-includes@ was used.
      
      Dropped the legacy 'lookupRenaming' export from ModuleRenaming and
      PackageDescription; we will shortly not use it anymore. As an
      intermediate hack we have a local definition in Configure, but this
      will go away shortly.
      1017f710
    • Edward Z. Yang's avatar
      Backpack InstalledPackageInfo representation changes · 3de0e4c4
      Edward Z. Yang authored
      New field, @instantiated-with@, which records the full
      module substitution (it is dropped when we do 'improveUnitId').
      
      For flexibility in the case of indefinite packages, some
      occurences of Module are relaxed to IndefModule (exposedReexport).
      This is just for convenience; in the case of a definite package
      these reexports and instantiations are guaranteed to be 'Module's.
      
      This patch also includes the minimal changes in other modules
      needed due to the representation change.
      3de0e4c4
    • Edward Z. Yang's avatar
      Introduce the new representation of UnitId · d7bd9078
      Edward Z. Yang authored
      'SimpleUnitId' constructor renamed to 'UnitId', and augmented
      with a new field 'Maybe String' recording a hash that uniquely
      identifies an instantiated unit of the library 'ComponentId'.
      'UnitId' can't be used to represent partially instantiated
      unit identifiers; see Distribution.Backpack for how we handle that.
      
      Previous uses of 'SimpleUnitId' should now use 'newSimpleUnitId'.
      'unitIdComponentId' folded into a record selector for 'ComponentId'.
      d7bd9078
  23. 30 Sep, 2016 1 commit
  24. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      
      Finally, this also adds a new functor-like convenience function
      
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      
      for modifying the version number components.
      bb2026c4
  25. 27 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `PackageName` type opaque (#3896) · dabd9d98
      Herbert Valerio Riedel authored
      When looking at heap-profiles of `cabal-install`, the `(:)` constructor
      stands out as the most-allocated constructor on the heap.
      
      Having to handle 10k+ package names contributes to the allocation
      numbers, especially on 64bit archs where ASCII `String`s have a 24 byte
      per character footprint.
      
      This commit is a preparatory commit to pave the way for changing
      `PackageName`'s internal representation to something like
      `ShortByteString` (which is essentially a thin wrapper around primitive
      `ByteArray#`s which themselves have have an overhead of 2 words + one
      byte per ASCII character rounded up to nearest word) which would allow
      to reduce the memory footprint by a full order of magnitude, as well as
      reduce pointer chasing and GC overhead.
      dabd9d98
  26. 22 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Update default-language & avoid default-extensions (#3880) · f87738df
      Herbert Valerio Riedel authored
      This upgrades the `default-language: Haskell98` to `Haskell2010`
      and removes `default-extensions: RankNTypes, FlexibleContexts`
      in favor of adding `LANGUAGE` pragmas where needed.
      
      Moroever, this also drops `LANGUAGE` pragmas which have become redundant
      due to `Haskell2010` (specifically, `EmptyDataDecls`,
      `ForeignFunctionInterface` and `PatternGuards`)
      
      Finally, an `other-extensions` specification is put in place for the
      `Cabal` library component.
      
      This helps loading up files directly in GHCi, such as e.g. `ghci Setup.hs`
      without having to specify `-X...` flags.
      f87738df
  27. 19 Sep, 2016 2 commits
    • Edward Z. Yang's avatar
      Never use --enable-profiling when invoking Setup. · bf3d3e68
      Edward Z. Yang authored
      
      
      In Cabal 1.22.5.0, the semantics of
      --disable-profiling/--enable-profiling depend on ordering (because there
      is a hack that operates by looking at the current flag assignment and
      doing something). In particular, if I specify --enable-library-profiling
      --disable-profiling, I end up with library profiling DISABLED.
      
      The fix is that we NEVER pass --enable-profiling or --disable-profiling
      to Cabal. At the moment, and according to my historical analysis, Cabal
      ONLY uses configProf to affect the effective library/executable
      profiling, which means that anything we do with --enable-profiling, we
      can do using the library/executable profiling individually. Since these
      are always flags for the versions of Cabal library we support, we will
      get order invariance. Historical versions have varied on whether or not
      setting executable profiling implies library profiling, but if we set
      both explicitly this change in behavior doesn't matter.
      
      This patch is difficult to test because the bad profiling flags
      can't be induced on an inplace build.  I tested by hand by building
      a package that depended on 'distributive' by hand.
      
      Fixes #3790.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bf3d3e68
    • Edward Z. Yang's avatar
  28. 18 Sep, 2016 2 commits
    • Edward Z. Yang's avatar
      Use enabledBuildInfos rather than allBuildInfo. · b17a45e9
      Edward Z. Yang authored
      
      
      In many places, we incorrectly used allBuildInfo, which
      returns all BuildInfos that are buildable, and not
      necessarily the ones we are actually going to *build*.
      This used to "mostly do the right thing" because we
      literally edited the PackageDescription to nub out things,
      so you wouldn't see non-enabled components anyway.  However
      when I added support for per-component configure, I stopped
      editing the PackageDescription, which meant all of these
      uses were wrong.
      
      So, I updated them to do the right thing. Note that there
      are still uses of allBuildInfo in Check, but that probably
      requires a closer look.
      
      Fixes #3847.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b17a45e9
    • Edward Z. Yang's avatar
      Refactor ComponentEnabledSpec into ComponentRequestedSpec. · d03fe594
      Edward Z. Yang authored
      
      
      In the previous documentation for 'ComponentEnabledSpec', I claimed
      that enabled components were buildable, as well as requested
      by the user.  In the course of working on #3847, however,
      I realized that I hadn't actually *checked* that the component
      was buildable anywhere.  In particular, the 'ComponentDisabled'
      reason was *never used*.  This mostly didn't cause problems,
      however, because when we 'flattenPD' all non-buildable components
      get deleted, so you basically never actually have a non-buildable
      'Component'.
      
      But it still seemed a bit silly, so I fixed it by doing this:
      
      1) I introduce a new concept of a component being requested,
      which captures the use of --enable-tests and friends.  This
      does NOT imply buildability.  Renamed ComponentEnabledSpec
      to ComponentRequestedSpec
      
      2) A component is enabled if it is requested and buildable.
      If you give me a Component and a ComponentRequestedSpec I
      can tell you if it's enabled.  However, if you give me a
      ComponentName I can't, because I have no idea if it's buildable.
      
      3) Stopped reexporting ComponentRequestedSpec from
      Distribution.Simple.LocalBuildInfo
      
      4) Added a test for attempting to specify a non-buildable
      component as a target.  The test is accepting suboptimal
      output at the moment, see #3858.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d03fe594
  29. 11 Sep, 2016 1 commit