This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 02 Nov, 2017 1 commit
  2. 01 Nov, 2017 1 commit
    • Moritz Angermann's avatar
      Adds sSources and cmmSources. · 4a287659
      Moritz Angermann authored
      # Conflicts:
      #	Cabal/Distribution/PackageDescription/Check.hs
      #	Cabal/Distribution/PackageDescription/Parsec/FieldDescr.hs
      #	Cabal/Distribution/Parsec/Types/FieldDescr.hs
      #	Cabal/doc/developing-packages.rst
      4a287659
  3. 27 Oct, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Make `FlagAssignment` an opaque `newtype` · 6cb6a516
      Herbert Valerio Riedel authored
      This is a refactoring abstracting `FlagAssignment` while retaining its
      external appearance as much as possible (i.e. same Read/Show/Binary
      instances etc).
      
      Later we can attach new instances, enforce internal invariants (like
      e.g. uniqueness of flagnames), switch out the internal
      representation (maybe to `Data.Map`), etc more easily.
      6cb6a516
  4. 20 Aug, 2017 1 commit
    • Daniel Gröber (dxld)'s avatar
      Demote 'scope' field version check to a warning · 8cd33192
      Daniel Gröber (dxld) authored
      In order to migrate from pre `scope` Setup.hs hacks to 2.0 we would like
      to specify both `scope` and `x-scope` (as just `scope` can't be accessed
      from Setup.hs AFAIK) and handle Cabal<2.0 with custom logic. However
      this check makes this undistributable as hackage would reject the
      package.
      8cd33192
  5. 17 Aug, 2017 2 commits
  6. 16 Aug, 2017 1 commit
  7. 14 Aug, 2017 2 commits
  8. 05 Aug, 2017 1 commit
  9. 08 Jul, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Implement `cabal check` for consistent .cabal naming (#4592) · ca60819d
      Herbert Valerio Riedel authored
      Hackage requires the .cabal file to be named consistently with the package name,
      but `cabal check` didn't detect this yet.
      
      Example output:
      
          $ cabal check
          The following errors will cause portability problems on other environments:
          * The filename ./doo.cabal does not match package name (expected: foobar.cabal)
      
          Hackage would reject this package.
      
      Note: this new check is implicitly/accidentally tested by an existing (unrelated)
      test in `cabal-testsuite`.
      ca60819d
  10. 22 Jun, 2017 1 commit
  11. 05 May, 2017 1 commit
  12. 03 Mar, 2017 1 commit
  13. 23 Jan, 2017 1 commit
  14. 06 Jan, 2017 3 commits
  15. 17 Dec, 2016 1 commit
  16. 14 Nov, 2016 1 commit
  17. 31 Oct, 2016 1 commit
  18. 29 Oct, 2016 1 commit
  19. 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
  20. 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
  21. 12 Oct, 2016 1 commit
  22. 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
  23. 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
  24. 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
  25. 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
  26. 11 Sep, 2016 2 commits
  27. 09 Sep, 2016 1 commit
  28. 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
  29. 01 Sep, 2016 1 commit
  30. 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
  31. 26 Jul, 2016 2 commits