This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 01 Nov, 2016 1 commit
  2. 31 Oct, 2016 3 commits
  3. 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
  4. 25 Oct, 2016 2 commits
    • 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
    • Edward Z. Yang's avatar
      Don't use installedPkgs for internal library library dirs. · a1107e21
      Edward Z. Yang authored
      In 1.24, installedPkgs contained only references to the external package
      database, not any internal libraries. In particular, when we built a
      dynamically linked executable, installedPkgs did NOT have a reference to
      the internal library; instead, depLibraryPaths has a special case
      (hasInternalDeps) to add the final libdir to the RPATH.
      
      In HEAD, after 0d15edef
      
      , we started adding internal libraries (with the
      INPLACE registrations) to installedPkgs to fix #2971.  But depLibraryPaths
      was not updated, which means that the inplace registrations got picked
      up and added to the RPATH, resulting in bad temporary directories
      showing up in RPATHs.
      
      In this commit, we just filter out internal entries from installedPkgs
      and compute the library dirs for them from scratch (this code already
      existed, so no loss!)
      
      Fixes #4025.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      a1107e21
  5. 20 Oct, 2016 2 commits
    • Edward Z. Yang's avatar
      Only consider dependencies in closure when computing -I on hsc2hs · b736896a
      Edward Z. Yang authored
      
      
      Previously, we unconditionally blasted in all packages, even
      if our component didn't actually depend on them.
      This fixes #2971.
      
      Also, added a test T2971a which is the opposite problem; previously
      we didn't bring in include-dirs from internal libraries.  That
      was fixed by the previous commit.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b736896a
    • 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
  6. 18 Oct, 2016 7 commits
  7. 17 Oct, 2016 1 commit
  8. 08 Oct, 2016 1 commit
  9. 06 Oct, 2016 3 commits
  10. 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
  11. 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
  12. 01 Sep, 2016 1 commit
  13. 21 Aug, 2016 2 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      One-component configure, fixes #2802. · a090a494
      Edward Z. Yang authored
      Described in: https://github.com/ghc-proposals/ghc-proposals/pull/4
      
      
      
      ./Setup configure now takes an argument to specify a specific
      component name that should solely be configured.
      
      Most of the gyrations in Configure are all about making it so that
      we can feed in internal dependencies via --dependency.
      
      I dropped the package name match sanity check to handle convenience
      library package name munging.  Consider an internal library named
      'q' in package 'p'.  When we install it to the package database,
      we munged the package name into 'z-p-z-q', so that it doesn't
      conflict with the actual package named 'q'.  Now consider when
      we feed it in with --dependency q=p-0.1-hash-q.  Previously,
      Cabal checked that the 'q' in --dependency matched the package
      name in the database... which it doesn't. So I dropped the check.
      
      I also had to make register/copy unconditionally install internal
      libraries; otherwise you can't refer to them from later builds.
      
      Also a miscellaneous refactor: convenience libraries are printed with a
      "header" stanza now (not really a stanza header).
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      a090a494
  14. 11 Aug, 2016 1 commit
    • fmaste's avatar
      Add new 'autogen-modules' field · c0108673
      fmaste authored
      Modules that are built automatically at setup, like Paths_PACKAGENAME or others created with a build-type custom, appear on 'other-modules' for the Library, Executable, Test-Suite or Benchmark stanzas or also on 'exposed-modules' for libraries but are not really on the package when distributed. This makes commands like sdist fail because the file is not found, so with this new field modules that appear there are treated the same way as Paths_PACKAGENAME was and there is no need to create complex build hooks.
      Just add the module names on 'other-modules' and 'exposed-modules' as always and on the new 'autogen-modules' besides.
      c0108673
  15. 24 Jul, 2016 1 commit
    • Edward Z. Yang's avatar
      As much as possible, expunge uses of localPkgDescr. · e3c64e6d
      Edward Z. Yang authored
      
      
      The big change here is that most of the functions in
      Distribution.Types.HookedBuildInfo have to take a
      PackageDescription explicitly.  I hate the new type,
      so I primed these new functions, and added functions
      which use 'localPkgDescr'.  Presently those have WARNINGs
      attached to them so people don't accidentally use them;
      once we fix 'HookedBuildInfo' we can change this.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e3c64e6d
  16. 23 Jul, 2016 2 commits
    • Edward Z. Yang's avatar
      Refactor LocalBuildInfo interface. · d94ddc0e
      Edward Z. Yang authored
      
      
      This is an omnibus patch, with the overall goal of making
      LocalBuildInfo Great Again.  The essential ideas:
      
      * New type 'TargetInfo' which bundles together 'ComponentLocalBuildInfo'
        and 'Component'.  Eventually, it will also record file paths / module
        targets.  This data structure is basically what you want; a lot of
        old Cabal code did lots of gyrations converting from
        'ComponentLocalBuildInfo' to 'Component' and vice versa, now
        it's all centralized.
      
      * The "new" API for 'LocalBuildInfo' is in
        "Distribution.Types.LocalBuildInfo".  The general principle
        is, where we previous dealt in 'ComponentLocalBuildInfo',
        we now deal in 'TargetInfo'.  There are shockingly few
        functions we need!
      
      * I've restored 'componentsConfigs' to its Cabal 1.24 signature
        for BC.
      
      * I killed a number of unused functions from "Distribution.Simple.LocalBuildInfo":
        'getLocalComponent', 'maybeGetDefaultLibraryLocalBuildInfo',
        'maybeGetComponentLocalBuildInfo', 'checkComponentsCyclic' and
        'enabledComponents'.  For each I checked on Hackage that they were
        not used.
      
      * 'getComponentLocalBuildInfo', 'withComponentsInBuildOrder' and
        'componentsInBuildOrder' are deprecated to encourage people
        to instead use the 'TargetInfo's to finger which components
        they want built.
      
      * 'ComponentLocalBuildInfo' now stores internally the computed
        'componentInternalDeps', so that 'LocalBuildInfo' can simply store
        a graph of 'ComponentLocalBuildInfo'.
      
      * The code in Configure has been streamlined to use our new Graph
        data type to great success.
      
      * The type of 'runTest' changed to take a 'ComponentLocalBuildInfo',
        bringing it more in line with everything else.
      
      * New function 'readTargetInfos' which combines 'readBuildTargets'
        and 'checkBuildTargets', which is what you really wanted anyway.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d94ddc0e
    • Herbert Valerio Riedel's avatar
      Implement `--allow-older` (dual to `--allow-newer`) (#3466) · 5944c3e9
      Herbert Valerio Riedel authored
      This implements the flag `--allow-older` which is the analogous to
      `--allow-newer` acting on lower bounds.
      5944c3e9
  17. 22 Jul, 2016 1 commit
  18. 15 Jul, 2016 1 commit
  19. 17 May, 2016 1 commit
  20. 12 Apr, 2016 6 commits