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. 19 Feb, 2017 1 commit
  4. 05 Jan, 2017 1 commit
  5. 29 Nov, 2016 1 commit
  6. 14 Nov, 2016 1 commit
  7. 31 Oct, 2016 1 commit
  8. 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
  9. 06 Oct, 2016 1 commit
  10. 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
  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. 08 Sep, 2016 1 commit
    • 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
  13. 30 Aug, 2016 1 commit
  14. 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
  15. 26 Jul, 2016 2 commits
  16. 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
  17. 23 Jul, 2016 1 commit
    • 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
  18. 22 Jul, 2016 1 commit
  19. 21 Jul, 2016 1 commit
  20. 29 Mar, 2016 2 commits
    • 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
  21. 30 Jan, 2016 1 commit
  22. 25 Jan, 2016 1 commit
  23. 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
  24. 16 Dec, 2015 2 commits
  25. 27 Nov, 2015 1 commit
  26. 01 Nov, 2015 1 commit
  27. 06 Mar, 2015 1 commit
  28. 18 Jan, 2015 1 commit
  29. 10 Dec, 2014 1 commit
  30. 09 Sep, 2013 1 commit
  31. 23 Aug, 2013 1 commit
  32. 10 Jul, 2013 1 commit
  33. 17 Feb, 2013 1 commit
  34. 17 Dec, 2012 1 commit
  35. 26 Nov, 2012 1 commit
    • Duncan Coutts's avatar
      New module for handling build targets given on the command line · 6b26957f
      Duncan Coutts authored
      This will be used for the new "cabal build [target]" feature and
      similarly for "cabal repl [target]". That is we can actually specify
      what we want to build, like a proper build system.
      
      Targets can be components, modules or files. We go to some effort to
      allow targets to be specified in a short convenient form. We allow
      case insensitive matching. We only complain when the given form is
      ambiguous (and note that we don't let the case insensitive matching
      add artificial ambiguity). If it is ambiguous we report the
      non-ambigious qualified forms of the targets it could be, e.g.:
      
        Ambiguous build target 'darcs'. It could be:
        exe:darcs (component)
        lib:darcs (component)
      
      We note the kind of target here (component, module, file) since it's
      possible to have ambiguities between them, like a component called
      'Foo' and a module 'Foo' if the user entered 'foo'.
      6b26957f