This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 17 Dec, 2016 1 commit
  2. 14 Nov, 2016 1 commit
  3. 31 Oct, 2016 1 commit
  4. 29 Oct, 2016 1 commit
  5. 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
  6. 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
  7. 12 Oct, 2016 1 commit
  8. 06 Oct, 2016 3 commits
    • 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
      Rename .cabal required-signatures field to signatures · 8d31f43b
      Edward Z. Yang authored
      Change of .cabal file syntax: rename @required-signatures@ field to
      just @signatures@. Update the parser and error messages that mention
      the field.
      
      Also rename the corresponding field in the Library type.
      8d31f43b
    • Edward Z. Yang's avatar
  9. 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
  10. 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
  11. 18 Sep, 2016 1 commit
    • 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. 11 Sep, 2016 2 commits
  13. 09 Sep, 2016 1 commit
  14. 08 Sep, 2016 2 commits
    • Edward Z. Yang's avatar
      Provide useful call-stacks over all IO code. · 48a0d6ce
      Edward Z. Yang authored
      
      
      The key idea is that we define:
      
          type IO a = HasCallStack => Prelude.IO a
      
      and voila, call stacks are maintained across all IO!  You can
      look at the stacks using -v"debug +callstack".
      
      There are a number of IO functions for which the call stack is
      never used.  They are explicitly annotated using NoCallStackIO.
      Maybe some day they will use call stacks and we can change their
      types.  Similarly, there are a number of functions which do
      have type IO, but then suppress the redundant constraint error
      using "_ = callStack". Maybe some day we will attach call
      stacks to the exceptions we throw.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      48a0d6ce
    • Lennart Kolmodin's avatar
      Use platform independant isRelative. · 91da15fa
      Lennart Kolmodin authored
      We can't use the one from System.FilePath since we don't know if we're
      dealing with Windows or Posix paths. See comments in code for more
      detail.
      91da15fa
  15. 01 Sep, 2016 1 commit
  16. 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
  17. 26 Jul, 2016 2 commits
  18. 24 Jul, 2016 1 commit
    • Edward Z. Yang's avatar
      Implement --cabal-file, allows multiple Cabal files in directory · e507ca84
      Edward Z. Yang authored
      
      
      This is primarily intended for use with the Cabal test suite (allowing
      us to easily specify multiple Cabal packages for the same Haskell source
      files), but maybe some end-users will find it useful as well.  If there
      are multiple Cabal files in the current working directory, --cabal-file
      (for configure) allows you to disambiguate which one to build with.
      
      There's a big hack to handle the BOM check, as it is inconvenient to
      plumb the flag value all the way to the check code.  Some bigger
      refactoring needed, see #3552.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e507ca84
  19. 23 Jul, 2016 3 commits
    • Mikhail Glushenkov's avatar
      80-col violations. · 3460b977
      Mikhail Glushenkov authored
      3460b977
    • Mikhail Glushenkov's avatar
      e0515186
    • Herbert Valerio Riedel's avatar
      New `cabal check` to warn about suspiciously short descriptions (#3479) · 165b6a05
      Herbert Valerio Riedel authored
      It seems that package authors are often unaware of the purpose of
      synopsis/description fields, and their impact on cabal and Hackage.  A
      common mistake is to write a verbose synopsis and leave the description
      field empty or even worse with useless boilerplate-text filled in by
      tooling, resulting in a suboptimal presentation on Hackage.
      
      The `synopsis` is supposed to be a terse <80 char description. In fact,
      the cabal user's guide states:
      
      > A very short description of the package, for use in a table of
      > packages. This is your headline, so keep it short (one line) but as
      > informative as possible. Save space by not including the package name
      > or saying it’s written in Haskell.
      
      On Hackage this synopsis is printed in the `<title>` and at the top of the
      package page, and is difficult to spot. However, the synopsis is
      displayed on Hackage in package lists or search results.
      
      On the other hand, the `description` field is rather important for
      `cabal info`  as well as the package cover-page, as it's printed below
      the "The $PKGNAME package"-heading, and above the properties section,
      and that's where everyone looks at.
      
      This new lint check is an attempt to point out a suspiciously short
      description field by using the heuristic of expecting the description
      field to be longer than the synopsis.
      165b6a05
  20. 22 Jul, 2016 1 commit
  21. 21 Jul, 2016 2 commits
  22. 19 Jul, 2016 1 commit
  23. 20 May, 2016 2 commits
  24. 19 May, 2016 1 commit
  25. 29 Mar, 2016 3 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Implement "convenience libraries", fixes #269. · 2040c1c9
      Edward Z. Yang authored
      
      
      Convenience libraries are package-private libraries
      that can be used as part of executables, libraries, etc
      without being exposed to the external world.  Private
      libraries are signified using the
      
          library foo
      
      stanza.  Within a Cabal package, the name convenience library
      shadows the conventional meaning of package name in
      build-depends, so that references to "foo" do not indicate
      foo in Hackage, but the convenience library defined in the
      same package. (So, don't shadow Hackage packages!)
      
      This commit implements convenience libraries such that they
      ARE installed the package database (this prevents us from
      having to special case dynamically linked executables);
      in GHC 7.10 and later they are installed under the same
      package name as the package that contained them, but have
      a distinct "component ID" (one pay off of making the distinction
      between component IDs and installed package IDs.)
      
      There is a "default" library which is identified by the fact
      that its library name coincides with the package name.  There
      are some new convenience functions to permit referencing this.
      
      There are a few latent bugs in this commit which are fixed
      in later commits in this patchset.  (Those bugfixes required
      a bit of refactoring, so it's clearer if they're not
      with this patch.)
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2040c1c9
  26. 08 Mar, 2016 1 commit
    • gershomb's avatar
      update -prof Check message · c69dfb82
      gershomb authored
      The flag enable-executable-profiling warns to change it to just enable-profiling. So we'll fix that here too so we don't send people down an old path.
      c69dfb82
  27. 03 Mar, 2016 1 commit
  28. 20 Feb, 2016 1 commit
  29. 18 Feb, 2016 1 commit