GitLab

eg we have build-tools like "pg_config"

     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) []

Rather than having it in Version and its parser elsewhere.
The Package module already imports the Version module which exports the
VersionRange type.

They have all been moved to tests/UnitTest/
So we don't need so much CPP in the ordinary modules now.

Since we've dropped ghc-6.2 compatibility we can now use Data.Tree directly.

This assumes a permissive UTF8 decoder has inserted '\xfffd' as a replacement
character. We should check strictly for errors when we decode instead, though
it's nice to do that where we have some kind of error reporting infrastructure
which is why I've added it to the parser for the moment. The current error
message is not too bad, as it reports the line number.

Added readTextFile and writeTextFile which use UTF8. rawSystemStdout now
assumes the programs are producing output in UTF8 encoding.

Also print output and error messages etc in UTF8.

Have to define it locally since it only appeared in Data.List recently.

and stop exporting various internal stuff from PackageDescription.Parse
which was previously being used by the sanity checking code.

ghc-6.4 and above recognise the OPTIONS_GHC pragma.
ghc-6.6 and above recognise the LANGUAGE pragma.
Added OPTIONS_JHC and OPTIONS_NHC pragmas with equivalant flags.

Joint work with Thomas Schilling.
The sections and indeed fields (and if/else) can now use either explicit
brace {} style layout or indentation eg:
> library
>   exposed-modules: Blah
or
> library {
>   exposed-modules:
> }
layout style can be nested within explict braces style and vica versa.
Also add some more checks and relax the tab checks.
Unrecognised sections, like unrecognised fields, are not fatal errors,
so we could add sections in future without breaking old cabal.

"./" => "/"!) and we don't need it that much, right now.

I haven't checked that it looks right, but it is now accepted by haddock.

sorry folks, Compat.FilePath is gone

Also avoids quadratic behaviour on long fields.

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.

As discussed on the libraries list (Nov 2006), add a field Build-Type
which can be used to declare that this package uses one of the boilerplate
setup scripts.  This allows setupWrapper (used by cabal-setup and
cabal-install) to bypass the setup script in this case and perform
the setup actions itself.

Add support for warnings to the ParseResult type. Change existing
warnings from using Debug.Trace to use this new warning support.

I throw a parse error if this package has the wrong cabal version.
This is so that the user can get this error before getting an error
for eg. an unknown field.  Also check it in the sanity checker.

I just hard-code the cabal version in the source, it would be nicer if
we got it from the .cabal file.  cabal could include the version in
the cpp flags, but cabal's setup file needs to build without cabal, so
that wouldn't actually work for us ahem.

  tweak SHGetFolderPath
  preprocess: Hugs+MinGW: remove special case
  test *_HOST_OS (as well as *_TARGET_OS, which is there for old GHC's)
  take care of string literals while stripping comments
  rearrange so that we print "Compiling FFI stubs" at most once
  only run ffihugs on Main module if required
  add comment about older Windows versions
  Hugs only: avoid SHGetFolderPath for now
  convert input file paths to platform form (from Brian Smith)
  convert paths to native form at entry
  rename --builddir as --scratchdir to avoid clash with autoconf --build flag.

  doc: consolidate descriptions of preprocessors