This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 31 May, 2009 1 commit
  2. 11 Dec, 2008 1 commit
    • Duncan Coutts's avatar
      Make the compiler PackageDB stuff more flexible · 39a4e6bf
      Duncan Coutts authored
      We support using multiple package dbs, however the method for
      specifying them is very limited. We specify a single package db
      and that implicitly specifies any other needed dbs. For example
      the user or a specific db require the global db too. We now
      represent that stack explicitly. The user interface still uses
      the single value method and we convert internally.
      39a4e6bf
  3. 05 Dec, 2008 1 commit
  4. 28 Jun, 2008 1 commit
    • Duncan Coutts's avatar
      Update module headers · 0c993c84
      Duncan Coutts authored
      Use cabal-devel@haskell.org as the maintainer in most cases except for
      a few which were pre-existing modules copied from elsewhere or modules
      like L.H.Extension which really belong to libraries@haskell.org
      Remove the useless stability module. We have more detailed information
      on stability elsewhere (in the version number and user guide).
      Add more top level module documentation, taken from the source guide.
      0c993c84
  5. 26 Jun, 2008 1 commit
  6. 24 Mar, 2008 1 commit
  7. 21 Mar, 2008 1 commit
    • Duncan Coutts's avatar
      Add Text instance for CompilerFlavor and CompilerId · a7c1b3cf
      Duncan Coutts authored
      This is a tad subtle since we actually have two ways of parsing
      compiler flavours. One expects, or at least allows lower case names
      like "ghc" and "nhc98", the other uses Read/Show which gives "GHC"
      and "NHC". What we're doing here is only changing the first variety.
      The cases where we parse using Read (and display using Show) are not
      changed. At some point we'll switch those over to the more liberal
      parser, but not yet as we don't want to cause compatibility problems.
      a7c1b3cf
  8. 17 Mar, 2008 1 commit
    • mnislaih's avatar
      #223 part 1: Extend Distribution.Command.Simple.Option · 7bbbe596
      mnislaih authored
           so that it really represents an option and not just a flag.
           It's been renamed to OptionField as it models a field in a flags-like data structure. 
           
              data OptionField a = OptionField {
                optionName        :: Name,
                optionDescr       :: [OptDescr a] }
            
              data OptDescr a  = ReqArg Description OptFlags ArgDescr (ReadE (a->a))         (a -> [String])
                               | OptArg Description OptFlags ArgDescr (ReadE (a->a)) (a->a)  (a -> [Maybe String])
                               | ChoiceOpt [(Description, OptFlags, a->a, a -> Bool)]
      			 | BoolOpt Description OptFlags{-True-} OptFlags{-False-} (Bool -> a -> a) (a -> Bool)
            
            An option field can expand to several command line options, which are all defined together.
            For example, the compiler flag is defined as follows.
            
                  option [] ["compiler"] "compiler"
                     configHcFlavor (\v flags -> flags { configHcFlavor = v })
                     (choiceOpt [ (Flag GHC, ("g", ["ghc"]), "compile with GHC")
                                , (Flag NHC, ([] , ["nhc98"]), "compile with NHC")
                                , (Flag JHC, ([] , ["jhc"]), "compile with JHC")
                                , (Flag Hugs,([] , ["hugs"]), "compile with Hugs")])
            
            We can need to use several kinds of OptDescr for the same option, as in the 
            optimization Option (really a extreme case):
            
                  ,multiOption "optimization"
                     configOptimization (\v flags -> flags { configOptimization = v })
                     [optArg' "n" (Flag . flagToOptimisationLevel)
                      ....
                      ....
                              "Build with optimization (n is 0--2, default is 1)",
                      noArg (Flag NoOptimisation) []
      7bbbe596
  9. 12 Mar, 2008 1 commit
  10. 07 Mar, 2008 1 commit
  11. 27 Feb, 2008 1 commit
  12. 23 Jan, 2008 1 commit
  13. 31 Aug, 2007 1 commit
  14. 29 Aug, 2007 2 commits
  15. 28 Aug, 2007 2 commits
  16. 26 Aug, 2007 1 commit
  17. 17 Aug, 2007 1 commit
    • Duncan Coutts's avatar
      Rewrite the Program abstraction and the ProgramConfiguration database · 24fb1f9a
      Duncan Coutts authored
      Also make the follow on changes to everything that uses Program.
      The notion of a program is now split into the abstract notion of a program
      that we know about and might be able to configure, and a configured program
      that we can actually run. The ProgramConfiguration database is similarly
      split. We still keep user-supplied loation and arguments and use them when
      we configure programs. The abstract Program now has functions to search for
      the program on the system and for finding the version number. This allows
      for more generic configuration of programs.
      24fb1f9a
  18. 08 Aug, 2007 1 commit
  19. 07 Aug, 2007 1 commit
    • Duncan Coutts's avatar
      Add compilerExtensions field to Compiler and make each compiler fill it in · 264b7a17
      Duncan Coutts authored
      It's just a list of supported extensions and the corresponding compiler flags.
      For most compilers this is currently just a static list. For ghc 6.7 and above
      we query ghc to find the list of language extensions it supports.
      In each case the code has moved out into the compiler-specific modules and the
      core code treats it generically.
      The extensionsToFlags function has been split into two:
      extensionsToFlags which now returns the flags for the supported extensions and
      unsupportedExtensions which does what it says it does. This is because the two
      roles of the previous function were always used separately, never together.
      264b7a17
  20. 05 Aug, 2007 1 commit
  21. 04 Aug, 2007 4 commits
  22. 02 Aug, 2007 1 commit
  23. 01 Aug, 2007 1 commit
  24. 28 Jul, 2007 1 commit
  25. 09 Jul, 2007 1 commit
  26. 08 Jul, 2007 3 commits
  27. 14 Jan, 2007 1 commit
    • Simon Marlow's avatar
      Refactorings only · 49e3cdae
      Simon Marlow authored
      Here are a batch of refactorings to clean up parsing and parts of the
      simple build system.  This patch originated in a patch sent to
      cabal-devel@haskell.org with an intial implementation of
      configurations.  Since then we decided to go a different route with
      configurations, so I have separated the refactoring from the
      configurations patch.
      
      At this point, 2 tests fail for me, but I get the same 2 failures
      without this patch.
      49e3cdae
  28. 05 Oct, 2006 1 commit
  29. 08 Sep, 2006 1 commit
  30. 01 Sep, 2006 1 commit
  31. 27 Apr, 2006 1 commit
  32. 18 Mar, 2006 1 commit
  33. 06 Feb, 2006 1 commit