From duncan.coutts at worc.ox.ac.uk  Thu Mar  1 05:02:57 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Mar  1 04:56:12 2007
Subject: How to debug a segfault.
In-Reply-To: <45E5BC97.9090502@davidb.org>
References: <45E4D575.8030606@davidb.org> <45E55CE3.9030700@gmail.com>
	<45E5A95C.4050105@davidb.org> <45E5B3DE.3040601@davidb.org>
	<45E5BC97.9090502@davidb.org>
Message-ID: <1172743377.1018.425.camel@localhost>

On Wed, 2007-02-28 at 09:32 -0800, David Brown wrote:

> However, what I missed is that the hsc2hs target files are placed
> alongside the source, not in the dist directory.  I had been building
> zlib on x86 using the hs generated on an amd64 machine.  The offsets
> in the structures were wrong.

Ohh, nasty.

> How difficult would it be to have Cabal store the target files in the
> 'dist' directory with everything else?  This also makes revision
> control a little more challenging, because I have to hand-pick a few
> select .hs files to ignore, since the rest of my code is sitting right
> next to them.

That would be good. I don't suppose it's too hard, after all we put
other generated modules in dist (the paths module). We then just have to
add more -i search dirs.

I'd be happy to review cabal patches along these lines.

[ On the plus side, I'm glad it wasn't a bug in my zlib binding :-) ]

Duncan

From davve at dtek.chalmers.se  Mon Mar  5 14:07:09 2007
From: davve at dtek.chalmers.se (davve@dtek.chalmers.se)
Date: Mon Mar  5 18:59:55 2007
Subject: darcs patch: Add preliminary support for haddock-ghc (and 9 more)
Message-ID: <20070305190709.228D988BC@anubis.medic.chalmers.se>

Fri Sep 15 21:29:49 CEST 2006  davve@dtek.chalmers.se
  * Add preliminary support for haddock-ghc

Fri Dec 29 20:54:39 CET 2006  davve@dtek.chalmers.se
  * Make sure haddock-ghc really creates the output dir

Sun Dec 31 00:21:16 CET 2006  davve@dtek.chalmers.se
  * Add compilerPath to Paths_<pkg>

Fri Jan  5 22:22:24 CET 2007  davve@dtek.chalmers.se
  * Add -D__HADDOCK__ to haddock-ghc

Sat Jan  6 02:44:20 CET 2007  davve@dtek.chalmers.se
  * Generate GHC arguments usable for haddock-ghc

Sat Jan  6 02:48:01 CET 2007  davve@dtek.chalmers.se
  * Use -g option to send GHC arguments to haddock-ghc

Thu Jan 18 22:55:20 CET 2007  davve@dtek.chalmers.se
  * Don't send -cpp to haddock-ghc

Mon Feb  5 00:49:25 CET 2007  davve@dtek.chalmers.se
  * Synch Haddock-GHC changes with recent changes to Cabal

Mon Mar  5 17:53:42 CET 2007  davve@dtek.chalmers.se
  * Solve conflict

Mon Mar  5 20:00:45 CET 2007  davve@dtek.chalmers.se
  * Use only one haddock command
  This patch merges the haddock-ghc and haddock commands, treating the "haddock" 
  executable as haddock-ghc if the version is >= 2.0.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 45681 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070305/ba6187f5/attachment-0001.bin
From nanardon at nanardon.zarb.org  Thu Mar  8 11:09:14 2007
From: nanardon at nanardon.zarb.org (Olivier Thauvin)
Date: Thu Mar  8 11:01:12 2007
Subject: Cabal and rpm packageing
Message-ID: <200703081709.20066.nanardon@nanardon.zarb.org>

Hi, I am a mandriva contributor and the current maintainer of ghc and hugs.

haksell modules currently give headhash to find the best way to package it.

- we need to register it after installation, the order should be preserved
- they have dependencies between them it seems (ie to use missingh I need also 
to have filepath and hslogger installed).
- each package have to be build with each compiler.

Feel free to 

Rpm is not able really to preserve a installation order (partially because bug 
inside rpmlib).

For mandriva, I started some work to make haskell packaging easier. For now 
this concern only ghc (more popular, and hugs is not working properly: 
ERROR "/usr/share/hugs/packages/base/Text/ParserCombinators/ReadP.hs":156 - 
Syntax error in type expression (unexpected `.'), error not happening is 
using ghc on this file... another topic).

First step is to create a set of macros for makor cabal build step, aka 
configure, build, haddock, test, copy. I provide also a macro to setup 
trigger and so (un)register module on ghc changes.

The second is to automatically find dependencies and report it to rpm.
To do that I create a small programme set around cabal:

[olivier@andromede haskell-CabalRpmDeps]$ runhaskell Setup.hs configure
[...]
[olivier@andromede haskell-CabalRpmDeps]$ dist/build/cabalrpmprov/cabalrpmprov
haskell(CabalRpmDeps) = 0.0.1
[...]
[olivier@andromede haskell-CabalRpmDeps]$ dist/build/cabalrpmreq/cabalrpmreq
haskell(unix) = 1.0
haskell(haskell98) = 1.0
haskell(base) = 2.0
haskell(Cabal) = 1.1.6

The haskell(...) names are wanted to match rpm dependencies scheme.

The bad things is useally dependencies are find using files list from each 
packages. But I didn't any solution to query .hi files, and I am not sure 
they contains information I need.

So here I use the the cabal library to query the module from files in 
builddir, but it doesn't matter, the cabal package cannot be split.

Now I have to write scripts around those progs and checking everything works 
fine.

The darcs repos is accessible there (using darcsweb, the page the url to fetch 
the repos):

http://nanardon.zarb.org/darcsweb/darcsweb.cgi?r=haskell-CabalRpmDeps;a=summary

Comments welcome.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070308/14dff0fa/attachment.bin
From ross at soi.city.ac.uk  Thu Mar  8 11:35:03 2007
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Thu Mar  8 11:28:21 2007
Subject: Cabal and rpm packageing
In-Reply-To: <200703081709.20066.nanardon@nanardon.zarb.org>
References: <200703081709.20066.nanardon@nanardon.zarb.org>
Message-ID: <20070308163503.GA11019@soi.city.ac.uk>

On Thu, Mar 08, 2007 at 05:09:14PM +0100, Olivier Thauvin wrote:
> hugs is not working properly: 
> ERROR "/usr/share/hugs/packages/base/Text/ParserCombinators/ReadP.hs":156 - 
> Syntax error in type expression (unexpected `.'), error not happening is 
> using ghc on this file... another topic).

For Hugs, you need to add -98 when using Cabal.

From simonmarhaskell at gmail.com  Fri Mar  9 05:28:40 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Fri Mar  9 05:21:41 2007
Subject: darcs patch: Add preliminary support for haddock-ghc (and 9
	more)
In-Reply-To: <20070305190709.228D988BC@anubis.medic.chalmers.se>
References: <20070305190709.228D988BC@anubis.medic.chalmers.se>
Message-ID: <45F136D8.40107@gmail.com>

davve@dtek.chalmers.se wrote:
> Fri Sep 15 21:29:49 CEST 2006  davve@dtek.chalmers.se
>   * Add preliminary support for haddock-ghc
> 
> Fri Dec 29 20:54:39 CET 2006  davve@dtek.chalmers.se
>   * Make sure haddock-ghc really creates the output dir
> 
> Sun Dec 31 00:21:16 CET 2006  davve@dtek.chalmers.se
>   * Add compilerPath to Paths_<pkg>
> 
> Fri Jan  5 22:22:24 CET 2007  davve@dtek.chalmers.se
>   * Add -D__HADDOCK__ to haddock-ghc
> 
> Sat Jan  6 02:44:20 CET 2007  davve@dtek.chalmers.se
>   * Generate GHC arguments usable for haddock-ghc
> 
> Sat Jan  6 02:48:01 CET 2007  davve@dtek.chalmers.se
>   * Use -g option to send GHC arguments to haddock-ghc
> 
> Thu Jan 18 22:55:20 CET 2007  davve@dtek.chalmers.se
>   * Don't send -cpp to haddock-ghc
> 
> Mon Feb  5 00:49:25 CET 2007  davve@dtek.chalmers.se
>   * Synch Haddock-GHC changes with recent changes to Cabal
> 
> Mon Mar  5 17:53:42 CET 2007  davve@dtek.chalmers.se
>   * Solve conflict
> 
> Mon Mar  5 20:00:45 CET 2007  davve@dtek.chalmers.se
>   * Use only one haddock command
>   This patch merges the haddock-ghc and haddock commands, treating the "haddock" 
>   executable as haddock-ghc if the version is >= 2.0.

I think this patch should go in ... any other comments before I push it?

CHeers,
	Simon
From davve at dtek.chalmers.se  Fri Mar  9 08:17:20 2007
From: davve at dtek.chalmers.se (davve@dtek.chalmers.se)
Date: Fri Mar  9 08:35:13 2007
Subject: darcs patch: Add preliminary support for haddock-ghc (and 10 more)
Message-ID: <20070309131720.B274A459A@anubis.medic.chalmers.se>

Fri Sep 15 21:29:49 CEST 2006  davve@dtek.chalmers.se
  * Add preliminary support for haddock-ghc

Fri Dec 29 20:54:39 CET 2006  davve@dtek.chalmers.se
  * Make sure haddock-ghc really creates the output dir

Sun Dec 31 00:21:16 CET 2006  davve@dtek.chalmers.se
  * Add compilerPath to Paths_<pkg>

Fri Jan  5 22:22:24 CET 2007  davve@dtek.chalmers.se
  * Add -D__HADDOCK__ to haddock-ghc

Sat Jan  6 02:44:20 CET 2007  davve@dtek.chalmers.se
  * Generate GHC arguments usable for haddock-ghc

Sat Jan  6 02:48:01 CET 2007  davve@dtek.chalmers.se
  * Use -g option to send GHC arguments to haddock-ghc

Thu Jan 18 22:55:20 CET 2007  davve@dtek.chalmers.se
  * Don't send -cpp to haddock-ghc

Mon Feb  5 00:49:25 CET 2007  davve@dtek.chalmers.se
  * Synch Haddock-GHC changes with recent changes to Cabal

Mon Mar  5 17:53:42 CET 2007  davve@dtek.chalmers.se
  * Solve conflict

Mon Mar  5 20:00:45 CET 2007  davve@dtek.chalmers.se
  * Use only one haddock command
  This patch merges the haddock-ghc and haddock commands, treating the "haddock" 
  executable as haddock-ghc if the version is >= 2.0.

Fri Mar  9 14:08:37 CET 2007  davve@dtek.chalmers.se
  * Send GHC libdir to haddock-ghc and synch with recent changes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 51458 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070309/68e257da/attachment-0001.bin
From davve at dtek.chalmers.se  Fri Mar  9 08:23:44 2007
From: davve at dtek.chalmers.se (David Waern)
Date: Fri Mar  9 08:35:14 2007
Subject: darcs patch: Add preliminary support for haddock-ghc (and 9
	more)
In-Reply-To: <45F136D8.40107@gmail.com>
References: <20070305190709.228D988BC@anubis.medic.chalmers.se>
	<45F136D8.40107@gmail.com>
Message-ID: <F1B9F6A2-A4C7-4256-86E6-99F1546E5314@dtek.chalmers.se>

> I think this patch should go in ... any other comments before I  
> push it?
>
> CHeers,
> 	Simon

This patch is now out of synch. I've attached a new patch that fixes  
this (with some additional changes).

/David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-haddock-cabal.patch
Type: application/octet-stream
Size: 51458 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070309/89731630/new-haddock-cabal-0001.obj
-------------- next part --------------


From simonmarhaskell at gmail.com  Fri Mar  9 11:07:50 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Fri Mar  9 11:00:50 2007
Subject: darcs patch: setup makefile
Message-ID: <45F18656.9020104@gmail.com>

I'm sending this patch here to solicit comments.

Ian Lynagh has been converting GHC's build system to use Cabal for packages 
instead of our current Makefile setup.  There are a couple of things that don't 
work as well with Cabal: (1) we can't use 'make -j' and get parallel builds, and 
(2) we can't build individual files and give extra options on the command line: 
this is occasionally very useful when debugging the compiler or testing small 
changes.

So we could fix these with brute force: I have patches to make GHC --make work 
in parallel, but it needs a lot of work to make it robust.  We could add support 
to Cabal to build a single file and give extra options on the command line, but 
most people don't need this.

Instead, I decided to address both of these in one go: the idea is to have Cabal 
generate a Makefile that you can use with 'make -j' or to build a single file 
with 'make dist/build/Foo.o', for example.  It only works with GHC, and only for 
libraries (I could probably make it work for executables too, just haven't done 
that yet).  It does work with profiling, and as far as I can tell everything 
else works, because GHC gets invoked with almost exactly the same arguments as 
with 'setup build', except that it is invoked one file at a time.

This is really the missing piece needed to let GHC use Cabal for its build 
system, so I'm pretty keen for this to go in.  Comments?

Cheers,
	Simon
-------------- next part --------------

New patches:

[Add 'setup makefile' command
Simon Marlow <simonmar@microsoft.com>**20070309155022
 'setup makefile' generates a Makefile that performs the steps
 necessary to compile the Haskell sources to object code.  This only
 works for libraries, and only with GHC right now.
 
 Instead of simply 'setup build', you can do this:
 
   $ ./setup makefile
   $ make
   $ ./setup build
 
 where './setup makefile' does the preprocessing and generates a
 Makefile tailored to the current package.  'make' will build all the
 Haskell code to object files, and 'setup build' will build any C code
 and the library archives.
 
 The reason for all this is that you can say 'make -j' and get a
 parallel build, or you can say
 
   make dist/build/Foo.o EXTRA_HC_OPTS=-keep-s-file
 
 to compile a single file with extra options.
] {
hunk ./Distribution/Make.hs 172
+
+            MakefileCmd -> exitWith ExitSuccess -- presumably nothing to do
hunk ./Distribution/Setup.hs 52
+                           MakefileFlags(..), emptyMakefileFlags,
hunk ./Distribution/Setup.hs 62
+                           parseMakefileArgs,
hunk ./Distribution/Setup.hs 97
+            | MakefileCmd             -- makefile
hunk ./Distribution/Setup.hs 253
+
+data MakefileFlags = MakefileFlags {makefileVerbose :: Int,
+                                    makefileFile :: Maybe FilePath}
+    deriving Show
+emptyMakefileFlags = MakefileFlags {makefileVerbose = 1,
+                                    makefileFile = Nothing}
+
hunk ./Distribution/Setup.hs 263
--- |Most of these flags are for Configure, but InstPrefix is for Copy.
+-- | All the possible flags
hunk ./Distribution/Setup.hs 302
+          -- For makefile:
+          | MakefileFile FilePath
hunk ./Distribution/Setup.hs 391
-commandList progConf = [(configureCmd progConf), buildCmd, cleanCmd, installCmd,
+commandList progConf = [(configureCmd progConf), buildCmd, makefileCmd,
+                        cleanCmd, installCmd,
hunk ./Distribution/Setup.hs 609
+makefileCmd :: Cmd a
+makefileCmd = Cmd {
+        cmdName        = "makefile",
+        cmdHelp        = "Perform any necessary makefileing.",
+        cmdDescription = "",  -- This can be a multi-line description
+        cmdOptions     = [cmd_help, cmd_verbose,
+           Option "f" ["file"] (reqPathArg MakefileFile)
+               "Filename to use (default: Makefile)."],
+        cmdAction      = MakefileCmd
+        }
+
+parseMakefileArgs :: MakefileFlags -> [String] -> [OptDescr a] -> IO (MakefileFlags, [a], [String])
+parseMakefileArgs = parseArgs makefileCmd updateCfg
+  where updateCfg mflags fl =
+           case fl of
+                Verbose n      -> mflags{makefileVerbose=n}
+                MakefileFile f -> mflags{makefileFile=Just f}
+
hunk ./Distribution/Simple/Build.hs 46
-	build
+	build, makefile
hunk ./Distribution/Simple/Build.hs 58
-import Distribution.Setup	 (CopyDest(..), BuildFlags(..) )
+import Distribution.Setup	( CopyDest(..), BuildFlags(..), 
+                                  MakefileFlags(..) )
hunk ./Distribution/Simple/Build.hs 75
-import Control.Monad 		( unless )
+import Control.Monad 		( unless, when )
hunk ./Distribution/Simple/Build.hs 92
-build :: PackageDescription  -- ^mostly information from the .cabal file
+build    :: PackageDescription  -- ^mostly information from the .cabal file
hunk ./Distribution/Simple/Build.hs 98
+  initialBuildSteps pkg_descr lbi verbose suffixes
+  setupMessage verbose "Building" pkg_descr
+  case compilerFlavor (compiler lbi) of
+    GHC  -> GHC.build  pkg_descr lbi verbose
+    JHC  -> JHC.build  pkg_descr lbi verbose
+    Hugs -> Hugs.build pkg_descr lbi verbose
+    _    -> die ("Building is not supported with this compiler.")
+
+makefile :: PackageDescription  -- ^mostly information from the .cabal file
+         -> LocalBuildInfo -- ^Configuration information
+         -> MakefileFlags -- ^Flags that the user passed to makefile
+         -> [ PPSuffixHandler ] -- ^preprocessors to run before compiling
+         -> IO ()
+makefile pkg_descr lbi flags suffixes = do
+  let verb = makefileVerbose flags
+  initialBuildSteps pkg_descr lbi verb suffixes
+  when (not (hasLibs pkg_descr)) $
+      die ("Makefile is only supported for libraries, currently.")
+  setupMessage verb "Generating Makefile" pkg_descr
+  case compilerFlavor (compiler lbi) of
+    GHC  -> GHC.makefile  pkg_descr lbi flags
+    _    -> die ("Generating a Makefile is not supported for this compiler.")
+
+
+initialBuildSteps pkg_descr lbi verbose suffixes = do
hunk ./Distribution/Simple/Build.hs 138
-  setupMessage verbose "Building" pkg_descr
-  case compilerFlavor (compiler lbi) of
-   GHC  -> GHC.build  pkg_descr lbi verbose
-   JHC  -> JHC.build  pkg_descr lbi verbose
-   Hugs -> Hugs.build pkg_descr lbi verbose
-   _    -> die ("Building is not supported with this compiler.")
hunk ./Distribution/Simple/GHC.hs 5
--- Copyright   :  Isaac Jones 2003-2006
+-- Copyright   :  Isaac Jones 2003-2007
hunk ./Distribution/Simple/GHC.hs 47
-	build, installLib, installExe
+	build, makefile, installLib, installExe
hunk ./Distribution/Simple/GHC.hs 50
+import Distribution.Setup       ( MakefileFlags(..) )
hunk ./Distribution/Simple/GHC.hs 90
+import System.IO
hunk ./Distribution/Simple/GHC.hs 355
-     ++ (if compilerVersion (compiler lbi) > Version [6,4] []
+     ++ ghcOptions lbi bi odir
+
+ghcOptions lbi bi odir
+     =  (if compilerVersion (compiler lbi) > Version [6,4] []
hunk ./Distribution/Simple/GHC.hs 378
+-- -----------------------------------------------------------------------------
+-- Building a Makefile
+
+makefile :: PackageDescription -> LocalBuildInfo -> MakefileFlags -> IO ()
+makefile pkg_descr lbi flags = do
+  let file = case makefileFile flags of
+                Just f ->  f
+                _otherwise -> "Makefile"
+  h <- openFile file WriteMode
+
+  let Just lib = library pkg_descr
+      bi = libBuildInfo lib
+  
+      ghc_vers = compilerVersion (compiler lbi)
+      packageId | versionBranch ghc_vers >= [6,4]
+                                = showPackageId (package pkg_descr)
+                 | otherwise = pkgName (package pkg_descr)
+  let decls = [
+        ("modules", unwords (exposedModules lib ++ otherModules bi)),
+        ("GHC", compilerPath (compiler lbi)),
+        ("WAYS", if withProfLib lbi then "p" else ""),
+        ("odir", buildDir lbi),
+        ("package", packageId),
+        ("GHC_OPTS", unwords (ghcOptions lbi bi (buildDir lbi))),
+        ("MAKEFILE", file)
+        ]
+  hPutStrLn h (unlines (map (\(a,b)-> a ++ " = " ++ munge b) decls))
+  hPutStrLn h makefileTemplate
+  hClose h
+ where
+  munge "" = ""
+  munge ('#':s) = '\\':'#':munge s
+  munge (c:s) = c : munge s
+
hunk ./Distribution/Simple/GHC.hs 497
+-- -----------------------------------------------------------------------------
+-- Makefile template
+
+makefileTemplate =
+ "GHC_OPTS += -package-name $(package) -i$(odir)\n"++
+ "\n"++
+ "# For adding options on the command-line\n"++
+ "GHC_OPTS += $(EXTRA_HC_OPTS)\n"++
+ "\n"++
+ "WAY_p_OPTS = -prof\n"++
+ "\n"++
+ "ifneq \"$(way)\" \"\"\n"++
+ "way_ := $(way)_\n"++
+ "_way := _$(way)\n"++
+ "GHC_OPTS += $(WAY_$(way)_OPTS)\n"++
+ "GHC_OPTS += -hisuf $(way_)hi -hcsuf $(way_)hc -osuf $(way_)o\n"++
+ "endif\n"++
+ "\n"++
+ "OBJS = $(patsubst %,$(odir)/%.$(way_)o,$(subst .,/,$(modules)))\n"++
+ "\n"++
+ "all :: .depend $(OBJS)\n"++
+ "\n"++
+ ".depend : $(MAKEFILE)\n"++
+ "	$(GHC) -M -optdep-f -optdep.depend $(foreach way,$(WAYS),-optdep-s -optdep$(way)) $(foreach obj,$(MKDEPENDHS_OBJ_SUFFICES),-osuf $(obj)) $(filter-out -split-objs, $(GHC_OPTS)) $(modules)\n"++
+ "	for dir in $(sort $(foreach mod,$(OBJS),$(dir $(mod)))); do \\\n"++
+ "		if test ! -d $$dir; then mkdir $$dir; fi \\\n"++
+ "	done\n"++
+ "\n"++
+ "include .depend\n"++
+ "\n"++
+ "# suffix rules\n"++
+ "\n"++
+ "ifneq \"$(odir)\" \"\"\n"++
+ "odir_ = $(odir)/\n"++
+ "else\n"++
+ "odir_ =\n"++
+ "endif\n"++
+ "\n"++
+ "$(odir_)%.$(way_)o : %.hs\n"++
+ "	$(GHC) $(GHC_OPTS) -c $< -o $@  -ohi $(basename $@).$(way_)hi\n"++
+ "\n"++
+ "$(odir_)%.$(way_)o : %.lhs	 \n"++
+ "	$(GHC) $(GHC_OPTS) -c $< -o $@  -ohi $(basename $@).$(way_)hi\n"++
+ "\n"++
+ "$(odir_)%.$(way_)o : %.c\n"++
+ "	@$(RM) $@\n"++
+ "	$(GHC) $(GHC_CC_OPTS) -c $< -o $@\n"++
+ "\n"++
+ "$(odir_)%.$(way_)o : %.$(way_)s\n"++
+ "	@$(RM) $@\n"++
+ "	$(GHC) $(GHC_CC_OPTS) -c $< -o $@\n"++
+ "\n"++
+ "$(odir_)%.$(way_)o : %.S\n"++
+ "	@$(RM) $@\n"++
+ "	$(GHC) $(GHC_CC_OPTS) -c $< -o $@\n"++
+ "\n"++
+ "$(odir_)%.$(way_)s : %.c\n"++
+ "	@$(RM) $@\n"++
+ "	$(GHC) $(GHC_CC_OPTS) -S $< -o $@\n"++
+ "\n"++
+ "%.$(way_)hi : %.$(way_)o\n"++
+ "	@if [ ! -f $@ ] ; then \\\n"++
+ "	    echo Panic! $< exists, but $@ does not.; \\\n"++
+ "	    exit 1; \\\n"++
+ "	else exit 0 ; \\\n"++
+ "	fi							\n"++
+ "\n"++
+ "%.$(way_)hi-boot : %.$(way_)o-boot\n"++
+ "	@if [ ! -f $@ ] ; then \\\n"++
+ "	    echo Panic! $< exists, but $@ does not.; \\\n"++
+ "	    exit 1; \\\n"++
+ "	else exit 0 ; \\\n"++
+ "	fi							\n"++
+ "\n"++
+ "$(odir_)%.$(way_)hi : %.$(way_)hc\n"++
+ "	@if [ ! -f $@ ] ; then \\\n"++
+ "	    echo Panic! $< exists, but $@ does not.; \\\n"++
+ "	    exit 1; \\\n"++
+ "	else exit 0 ; \\\n"++
+ "	fi\n"++
+ "\n"++
+ "show:\n"++
+ "	@echo '$(VALUE)=\"$($(VALUE))\"'\n"++
+ "\n"++
+ "\n"++
+ "ifneq \"$(strip $(WAYS))\" \"\"\n"++
+ "ifeq \"$(way)\" \"\"\n"++
+ "all ::\n"++
+ "# Don't rely on -e working, instead we check exit return codes from sub-makes.\n"++
+ "	@case '${MFLAGS}' in *-[ik]*) x_on_err=0;; *-r*[ik]*) x_on_err=0;; *) x_on_err=1;; esac; \\\n"++
+ "	for i in $(WAYS) ; do \\\n"++
+ "	  echo \"== $(MAKE) way=$$i -f $(MAKEFILE) $@;\"; \\\n"++
+ "	  $(MAKE) way=$$i -f $(MAKEFILE) --no-print-directory $(MFLAGS) $@ ; \\\n"++
+ "	  if [ $$? -eq 0 ] ; then true; else exit $$x_on_err; fi; \\\n"++
+ "	done\n"++
+ "	@echo \"== Finished recursively making \\`$@' for ways: $(WAYS) ...\"\n"++
+ "endif\n"++
+ "endif\n"++
+ "\n"++
+ "# We could consider adding this: the idea would be to have 'make' do\n"++
+ "# everything that 'setup build' does.\n"++
+ "# ifeq \"$(way)\" \"\"\n"++
+ "# all ::\n"++
+ "# 	./Setup build\n"++
+ "# endif\n"
+
hunk ./Distribution/Simple.hs 80
-import Distribution.Simple.Build	( build )
+import Distribution.Simple.Build	( build, makefile )
hunk ./Distribution/Simple.hs 157
+      -- |Hook to run before makefile command.  Second arg indicates verbosity level.
+     preMakefile  :: Args -> MakefileFlags -> IO HookedBuildInfo,
+
+     -- |Over-ride this hook to gbet different behavior during makefile.
+     makefileHook :: PackageDescription -> LocalBuildInfo -> Maybe UserHooks -> MakefileFlags -> IO (),
+      -- |Hook to run after makefile command.  Second arg indicates verbosity level.
+     postMakefile :: Args -> MakefileFlags -> PackageDescription -> LocalBuildInfo -> IO ExitCode,
+
hunk ./Distribution/Simple.hs 324
+            MakefileCmd ->
+                command (parseMakefileArgs emptyMakefileFlags) makefileVerbose
+                        preMakefile makefileHook postMakefile
+                        getPersistBuildConfig
+        
hunk ./Distribution/Simple.hs 603
+       preMakefile = rn,
+       makefileHook = ru,
+       postMakefile = res,
hunk ./Distribution/Simple.hs 642
+       makefileHook = defaultMakefileHook,
hunk ./Distribution/Simple.hs 675
+       preMakefile = readHook makefileVerbose,
hunk ./Distribution/Simple.hs 726
+      writeInstalledConfig pkg_descr localbuildinfo False
+
+defaultMakefileHook :: PackageDescription -> LocalBuildInfo
+	-> Maybe UserHooks -> MakefileFlags -> IO ()
+defaultMakefileHook pkg_descr localbuildinfo hooks flags = do
+  makefile pkg_descr localbuildinfo flags (allSuffixHandlers hooks)
+  when (hasLibs pkg_descr) $
hunk ./doc/Cabal.xml 1704
+
+    <sect2 id="setup-makefile">
+      <title>setup makefile</title>
+      <para>Generate a Makefile that may be used to compile the
+      Haskell modules to object code.  This command is currently only
+      supported when building libraries, and only if the compiler is
+      GHC.</para>
+
+      <para>The makefile replaces part of the work done by
+      <literal>setup build</literal>.  The sequence of commands would
+      typeically be:
+<programlisting>
+runhaskell Setup.hs makefile
+make
+runhaskell Setup.hs build
+</programlisting>
+      where <literal>setup makefile</literal> does the preprocessing,
+      <literal>make</literal> compiles the Haskell modules, and
+      <literal>setup build</literal> performs any final steps, such as
+      building the library archives.</para>
+
+      <para>The Makefile does not use GHC's <literal>--make</literal>
+      flag to compile the modules, instead it compiles modules one at
+      a time, using dependency information generated by GHC's
+      <literal>-M</literal> flag.  There are two reasons you might
+      therefore want to use <literal>setup makefile</literal>:
+
+      <itemizedlist>
+        <listitem>
+          <para>You want to build in parallel using <literal>make -j</literal>.
+          Currently, <literal>setup build</literal> on its own does not support
+          building in parallel.</para>
+        </listitem>
+        <listitem>
+          <para>You want to build an individual module, pass extra
+          flags to a compilation, or do other non-standard things that
+          <literal>setup build</literal> does not support.</para>
+        </listitem>
+      </itemizedlist>
+      </para>
+
+    </sect2>
}

Context:

[add Distribution.SetupWrapper to exposed-modules
Simon Marlow <simonmar@microsoft.com>**20070309122146] 
[Tweaks to make Cabal play nicer with haddock
Ian Lynagh <igloo@earth.li>**20070308155718
 
 The path for the html docs now includes the package name at the end,
 which works nicer for multiple packages sharing a contents/index.
 
 Use --ghc-pkg when available (in haddock darcs only currently) to tell
 haddock which ghc-pkg to use.
 
 Use --allow-missing-html when available (in haddock darcs only
 currently) to tell haddock not to worry if it can't find the HTML for
 packages we depend on. This is necessary when haddocking a group of
 packages before moving them all into place.
] 
[Cope with ghc-pkg telling us packages are broken
Ian Lynagh <igloo@earth.li>**20070307193131] 
[Tell GHC to use .hs mode when we want it to cpp something for us
Ian Lynagh <igloo@earth.li>**20070307143612] 
[Add parentheses so expressions are parsed correctly
Ian Lynagh <igloo@earth.li>**20070307131941] 
[minor refactoring
Ross Paterson <ross@soi.city.ac.uk>**20070301002731] 
[fix \begin{code typo
Ross Paterson <ross@soi.city.ac.uk>**20070301002557] 
[document the --with-compiler / --with-hc inconsistency
Ross Paterson <ross@soi.city.ac.uk>**20070225115601] 
[Clarify documentation on --with-compiler and --with-hc-pkg
simonpj@microsoft.com**20070221110452] 
[minor markup tweaks
Ross Paterson <ross@soi.city.ac.uk>**20070218104622] 
[This usePackages stuff is haddock-specific so name it as such
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20070213201434] 
[{en,dis}able-use-packages, -optP-P only if haddock<0.8
Conal Elliott <conal@conal.net>**20070204061106] 
[cabal-upload: Added command-line options for username, password, checking instead of uploading. Added ability to get login from file, and to get password from the terminal. Added still unused verbosity options. Bumped version number to 0.2.
bjorn@bringert.net**20070212232920] 
[exclude Setup.lhs
Ross Paterson <ross@soi.city.ac.uk>**20070212193608
 
 This was generating a useless Main entry in the lib doc index.
 (good for STABLE)
] 
[Add recent Cabal modules to nhc98 build system.
Malcolm.Wallace@cs.york.ac.uk**20070212171106] 
[Compatibility with Haskell'98.
Malcolm.Wallace@cs.york.ac.uk**20070212170804
 Import Distribution.Compat.Exception instead of Control.Exception.
 Fix illegal indentation of cascaded do-blocks.
] 
[add --enable-optimization/--disable-optimization config options (on by default)
Ross Paterson <ross@soi.city.ac.uk>**20070212004513] 
[cabal-upload: nicer output.
bjorn@bringert.net**20070206154619] 
[Send Accept header.
bjorn@bringert.net**20070206153521] 
[Allow uploading multiple packages.
bjorn@bringert.net**20070206153406] 
[Changed HTTP dependency to >= 1.0. 
bjorn@bringert.net**20070206153054] 
[cabal-upload: Removed build-simple since hackage doesn't seem to accept it for non-lib packages.
bjorn@bringert.net**20070206133616] 
[Added URL for cabal-upload wiki page.
bjorn@bringert.net**20070206132142] 
[Added usage message to cabal-upload.
bjorn@bringert.net**20070206131408] 
[Added a small hacky first version of cabal-upload.
bjorn@bringert.net**20070206112237] 
[cabal-setup doesn't need -cpp
Ross Paterson <ross@soi.city.ac.uk>**20070115154724] 
[Refactorings only
Simon Marlow <simonmar@microsoft.com>**20070114203741
 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.
] 
[pass arguments through when performing the setup actions ourselves
Ross Paterson <ross@soi.city.ac.uk>**20070113133211] 
[separate option for the compiler for Setup.hs
Ross Paterson <ross@soi.city.ac.uk>**20070113133000
 
 This need not be the same compiler as used to build the package
] 
[Ignoring user packages when installing locally doesn't make sense.
Lemmih <lemmih@gmail.com>**20070112150318] 
[cabal-install now caches downloaded packages in the directory for the package, and with .tar.gz extension.
bjorn@bringert.net**20070112143527] 
[cabal-install.cabal: Added build-type field. Change hs-source-dir to hs-source-dirs (hs-source-dir has been deprecated for some time).
bjorn@bringert.net**20070112131959] 
[cabal-install --user now keeps package cache and package list in ~/.cabal-install
bjorn@bringert.net**20070112131301] 
[fix ghc-options (not a listField)
bjorn@bringert.net**20070112124938] 
[add a Build-Type field, and use it in setupWrapper
Ross Paterson <ross@soi.city.ac.uk>**20070111233018
 
 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.
] 
[remove a use of null+head
Ross Paterson <ross@soi.city.ac.uk>**20070111182430] 
[remove two fromJust's
Ross Paterson <ross@soi.city.ac.uk>**20070111182401] 
[pass CABAL_VERSION to Hugs
Ross Paterson <ross@soi.city.ac.uk>**20070111182216] 
[cabal-install now puts the package list in /var/lib/cabal-install and the tarballs in /var/cache/cabal-install by default. Added command-line options for changing those.
bjorn@bringert.net**20070111190452] 
[Track verbosity argument changes
Ian Lynagh <igloo@earth.li>**20070111180601] 
[Testsuite quietening
Ian Lynagh <igloo@earth.li>**20070111175329] 
[cabal-install: Output usage info for the right command when pasrsing the package name arguments fails.
bjorn@bringert.net**20070111164924] 
[SetupWrapper now passes verbosity to other functions, as required by Igloo's patch.
bjorn@bringert.net**20070111161651] 
[Make cabal-install use setupWrapper (the library version of cabal-setup).
bjorn@bringert.net**20070111160535] 
[Moved the cabal-setup code to Distribution.SetupWrapper, so that cabal-install can use it. CabalSetup.hs now just calls the setupWrapper function.
bjorn@bringert.net**20070111130506] 
[Quieten the testsuite more
Ian Lynagh <igloo@earth.li>**20070111155957] 
[Pass verbosity info down to warn
Ian Lynagh <igloo@earth.li>**20070111154526] 
[Derive Show on various datatypes
Ian Lynagh <igloo@earth.li>**20070111140220] 
[Give feedback in runTests.sh
Ian Lynagh <igloo@earth.li>**20070111132654] 
[Be less verbose at verbosity level 1
Ian Lynagh <igloo@earth.li>**20070111131228] 
[Fix warning
Ian Lynagh <igloo@earth.li>**20070111130928] 
[No need for -fno-warn-unused-matches any more
Ian Lynagh <igloo@earth.li>**20070111130824] 
[Always pass Hooks around, not Maybe Hooks
Ian Lynagh <igloo@earth.li>**20070111124234] 
[Make Makefile use the right ghc/ghc-pkg
Ian Lynagh <igloo@earth.li>**20070111122833] 
[Add -Wall to GHCFLAGS
Ian Lynagh <igloo@earth.li>**20070111102742] 
[Updated cabal-install test scripts to use the main Cabal repo.
bjorn@bringert.net**20070111111727] 
[Added cabal-install test scripts.
bjorn@bringert.net**20070110184835] 
[Added cabal-install Makefile.
bjorn@bringert.net**20070110184754] 
[Added HTTP package code used by cabal-install.
bjorn@bringert.net**20070110184545] 
[Imported all the cabal-install sources.
bjorn@bringert.net**20070110183142] 
[Added cabal-install dep on regex-compat.
bjorn@bringert.net**20070110180020] 
[Removed old CabalInstall.hs (it has moved to cabal-install/src in one of the pataches I pulled in).
bjorn@bringert.net**20070110174435] 
[Pulling in cabal-install: changed default Hackage DB URL.
bjorn@bringert.net**20070110173825] 
[Pulling cabal-with-install into Cabal: cabal-install.cabal changes.
bjorn@bringert.net**20070110172811] 
[Pulling changes from cabal-with-install: Multiple repositories.
bjorn@bringert.net**20070110164852
 Original patch:
 Sat Sep  2 00:13:40 CEST 2006  Paolo Martini <paolo@nemail.it>
   * Multiple repositories.
] 
[Pulling changes from cabal-with-install: Stripping off the dependencies, only HTTP left
bjorn@bringert.net**20070110164556
 Original patch:
 Sun Aug 20 19:01:03 CEST 2006  Paolo Martini <paolo@nemail.it>
   * Stripping off the dependencies, only HTTP left
] 
[Resolve Makefile conflict from importing Cabal-with-install patches.
bjorn@bringert.net**20070110163852] 
[a program to test download & install a bunch of cabal packages
ijones@syntaxpolice.org**20061114063409] 
[added --inplace trick to cabal build so that cabal-install can build on machines without cabal.
ijones@syntaxpolice.org**20060922034620] 
[First attempt to make a new repository (url in the configuration)
Paolo Martini <paolo@nemail.it>**20060820180342] 
[Tarball index format support
Paolo Martini <paolo@nemail.it>**20060816223509] 
[Quieten a test
Ian Lynagh <igloo@earth.li>**20070110175223] 
[Pass 0 verbosity on to GHC when building
Ian Lynagh <igloo@earth.li>**20070110174050] 
[More verbosity tweaking
Ian Lynagh <igloo@earth.li>**20070110172956] 
[Rejig verbosity levels a bit; 1 is now the default (was 0)
Ian Lynagh <igloo@earth.li>**20070110165149] 
[Make system tweaks to avoid cabal thinking it isn't bootstrapped when running the testsuite
Ian Lynagh <igloo@earth.li>**20070110162940] 
[Typo
Ian Lynagh <igloo@earth.li>**20070110154617] 
[Refer to the right variables
Ian Lynagh <igloo@earth.li>**20070110151326] 
[Give unrecognised flags more clearly
Ian Lynagh <igloo@earth.li>**20070110144650] 
[Beautify
Ian Lynagh <igloo@earth.li>**20070110143711] 
[Retab
Ian Lynagh <igloo@earth.li>**20070110143103] 
[Remove some chatter from the test scripts
Ian Lynagh <igloo@earth.li>**20070110142756] 
[Eliminate more warnings
Ian Lynagh <igloo@earth.li>**20070110142114] 
[More -Wall clean fixes
Ian Lynagh <igloo@earth.li>**20070110135838] 
[Improve cleaning
Ian Lynagh <igloo@earth.li>**20070110134230] 
[-Wall clean fixes
Ian Lynagh <igloo@earth.li>**20070110125523
 
 This patch is sponsored by Hac 07.
 Have you hacked a lambda today?
] 
[Fix non-fatal problem with 'setup haddock' for an exe package
Simon Marlow <simonmar@microsoft.com>**20070109133751
 For some unknown reason, we were passing --use-package=P to haddock,
 where P is the name of the current executable package.  This can never
 work, since P is not a library and will not be installed.  Fortunately
 Haddock ignores the error and continues anyway.
 
] 
[Set the Cabal version when building via the fptools build system
sven.panne@aedion.de**20070106152814
 
 Without this patch, Cabal is effectively "version-less" and all .cabal
 files with a version requirement are unusable. Therefore I think that
 this patch (or at least something equivalent) should be pushed to the
 6.6.1 branch, too.
] 
[added --save-configure flag to clean. got some complaints that there was no way to avoid reconfiguring after a clean.  now if you use --save-configure, you should be able to.
ijones@syntaxpolice.org**20061219152204] 
[tiny mod to License comments
ijones@syntaxpolice.org**20061219060021] 
[improving help output
ijones@syntaxpolice.org**20061219055849
 As suggested by Claus Reinke in this ticket:
 http://hackage.haskell.org/trac/hackage/ticket/105
] 
[fix ./Setup unregister --help, which was giving the help for register
Simon Marlow <simonmar@microsoft.com>**20061215165000] 
[Fix the links in the user guide to the API docs
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>*-20061129131633] 
[Fix the links in the user guide to the API docs
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061129131633] 
[haddock comments for SrcDist.hs
ijones@syntaxpolice.org**20061127041303] 
[some haddock comments for LocalBuildInfo.hs
ijones@syntaxpolice.org**20061127040916] 
[a little comment for JHC.hs
ijones@syntaxpolice.org**20061127040026] 
[some comments for Install.hs
ijones@syntaxpolice.org**20061127035919] 
[some comments for Hugs.hs
ijones@syntaxpolice.org**20061127035310] 
[haddock comments for GHC and GHCPackageConig
ijones@syntaxpolice.org**20061127034617] 
[some comments for Configure.hs
ijones@syntaxpolice.org**20061127033157] 
[some comments for Build.hs
ijones@syntaxpolice.org**20061127032409] 
[minor comments and cleanup for Setup.hs
ijones@syntaxpolice.org**20061127031744] 
[some haddock explanation of preprocessors
ijones@syntaxpolice.org**20061127031055] 
[some comments for Package.hs
ijones@syntaxpolice.org**20061127025108] 
[haddockizing some comments from Make.hs
ijones@syntaxpolice.org**20061127024142] 
[adding comments to Program.hs
ijones@syntaxpolice.org**20061127022353] 
[comments for the Program module
ijones@syntaxpolice.org**20061127002749] 
[don't return an error code just because there's no library to register
ijones@syntaxpolice.org**20061124144831] 
[Purely cosmetic; have '--<FOO>-args' use ARGS on their RHS rather than PATH in usage output
sof@galois.com**20061121195844] 
[parse executable field as a token (as documented), rather than free text
Ross Paterson <ross@soi.city.ac.uk>**20061120093400] 
[trim trailing spaces (including CRs) from all input lines
Ross Paterson <ross@soi.city.ac.uk>**20061120092526] 
[help nhc98 find the import of programLocation
Malcolm.Wallace@cs.york.ac.uk**20061117144001] 
[sdist: make it work on Windows platforms by simplifying 'tar' invocation. Hopefully not at the cost of other plats (i.e., as-yet untested there..)"
sof@galois.com**20061117014832] 
[build: consult and use any user-provided settings for 'ld' and 'ar'
sof@galois.com**20061117014622] 
[defaultUserHooks.sDistHook: pass in optional LBI to SrcDist.sdist
sof@galois.com**20061117014448] 
[defaultProgramConfiguration: add 'ld' and 'tar' entries
sof@galois.com**20061117014318] 
[revise Paths module for the Hugs target
Ross Paterson <ross@soi.city.ac.uk>**20061108223349
 
 When targetting Hugs, the Paths module now uses prefix-independent
 paths relative to the location of the Main module of the program,
 on all platforms.
 
 For the Hugs target, this replaces the code using GetModuleFileNameA(),
 which never worked.  Behaviour under GHC should be unchanged.
] 
[Hugs: fix location of installed package info
Ross Paterson <ross@soi.city.ac.uk>**20061021144613] 
[Fix escaping of ' chars in register.sh script.
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061016215459] 
[Tidy up command comments
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061013211158] 
[Fix getDataDir etc. when bindir=$prefix
Simon Marlow <simonmar@microsoft.com>**20061013100941] 
[Update text on the front page: packages can now overlap in GHC 6.6
Simon Marlow <simonmar@microsoft.com>**20061012114601
 
] 
[New unlit code "ported" from cpphs-1.2
Lennart Kolmodin <kolmodin@dtek.chalmers.se>**20061009192609] 
[Share one more place where the cabal version is defined.
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010140027] 
[Fix spelling error in error message.
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010140013] 
[Centeralise the places that know that Cabal version number
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010135918] 
[Remove spurious debug message.
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010125643] 
[Bump to next unstable development version
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010125602] 
[Make cabal know it's own version number correctly
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010130939
 This is an unpleasent way of doing it.
 Will have to fix once and for all in the next version.
] 
[TAG 1.1.6
Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061009123801] 
Patch bundle hash:
343e137602e63baf88fb7c8cd0c5feac7c76d623
From simonmarhaskell at gmail.com  Fri Mar  9 11:37:32 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Fri Mar  9 11:30:31 2007
Subject: branches and merging
Message-ID: <45F18D4C.8070309@gmail.com>

Cabal has the following branches:

  HEAD, in darcs.haskell.org:/cabal, used by GHC HEAD
  1.1.6, in darcs.haskell.org/cabal-branches/cabal-1.1.6
  GHC 6.6 branch, in darcs.haskell.org/ghc-6.6/packages/Cabal

The official 1.1.6 is diverging from GHC's 6.6 version.  We should merge the two 
- Duncan would you like to take a look and see if you can pull from GHC's branch 
into 1.1.6, and then we can use 1.1.6 in GHC 6.6?

Also I just noticed that Ross's patch

Mon Nov 20 09:25:26 GMT 2006  Ross Paterson <ross@soi.city.ac.uk>
   * trim trailing spaces (including CRs) from all input lines

fixes #117 http://hackage.haskell.org/trac/hackage/ticket/117, and could easily 
be merged into 1.1.6.

Cheers,
	Simon
From bos at serpentine.com  Fri Mar  9 12:29:36 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Fri Mar  9 12:22:31 2007
Subject: darcs patch: setup makefile
In-Reply-To: <45F18656.9020104@gmail.com>
References: <45F18656.9020104@gmail.com>
Message-ID: <45F19980.5050401@serpentine.com>

Simon Marlow wrote:

> This is really the missing piece needed to let GHC use Cabal for its 
> build system, so I'm pretty keen for this to go in.  Comments?

Very nice.  This ought to be usable to build RPMs in parallel, too, 
which is something that rpmbuild likes to try to do by default.

	<b
From duncan.coutts at worc.ox.ac.uk  Sat Mar 10 10:56:48 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Mar 10 10:49:28 2007
Subject: darcs patch: setup makefile
In-Reply-To: <45F18656.9020104@gmail.com>
References: <45F18656.9020104@gmail.com>
Message-ID: <1173542208.1018.725.camel@localhost>

Simon,

Ultimately I'd like to cabal do the dependency analysis, be able to
rebuild any module (not just the lib/prog target) and do things like
parallel builds.

I'm well aware however that no one has the time at the moment to address
that.

Duncan

On Fri, 2007-03-09 at 16:07 +0000, Simon Marlow wrote:
> I'm sending this patch here to solicit comments.
> 
> Ian Lynagh has been converting GHC's build system to use Cabal for packages 
> instead of our current Makefile setup.  There are a couple of things that don't 
> work as well with Cabal: (1) we can't use 'make -j' and get parallel builds, and 
> (2) we can't build individual files and give extra options on the command line: 
> this is occasionally very useful when debugging the compiler or testing small 
> changes.
> 
> So we could fix these with brute force: I have patches to make GHC --make work 
> in parallel, but it needs a lot of work to make it robust.  We could add support 
> to Cabal to build a single file and give extra options on the command line, but 
> most people don't need this.
> 
> Instead, I decided to address both of these in one go: the idea is to have Cabal 
> generate a Makefile that you can use with 'make -j' or to build a single file 
> with 'make dist/build/Foo.o', for example.  It only works with GHC, and only for 
> libraries (I could probably make it work for executables too, just haven't done 
> that yet).  It does work with profiling, and as far as I can tell everything 
> else works, because GHC gets invoked with almost exactly the same arguments as 
> with 'setup build', except that it is invoked one file at a time.
> 
> This is really the missing piece needed to let GHC use Cabal for its build 
> system, so I'm pretty keen for this to go in.  Comments?
> 
> Cheers,
> 	Simon
> plain text document attachment (setup-makefile.patch)
> New patches:
> 
> [Add 'setup makefile' command
> Simon Marlow <simonmar@microsoft.com>**20070309155022
>  'setup makefile' generates a Makefile that performs the steps
>  necessary to compile the Haskell sources to object code.  This only
>  works for libraries, and only with GHC right now.
>  
>  Instead of simply 'setup build', you can do this:
>  
>    $ ./setup makefile
>    $ make
>    $ ./setup build
>  
>  where './setup makefile' does the preprocessing and generates a
>  Makefile tailored to the current package.  'make' will build all the
>  Haskell code to object files, and 'setup build' will build any C code
>  and the library archives.
>  
>  The reason for all this is that you can say 'make -j' and get a
>  parallel build, or you can say
>  
>    make dist/build/Foo.o EXTRA_HC_OPTS=-keep-s-file
>  
>  to compile a single file with extra options.
> ] {
> hunk ./Distribution/Make.hs 172
> +
> +            MakefileCmd -> exitWith ExitSuccess -- presumably nothing to do
> hunk ./Distribution/Setup.hs 52
> +                           MakefileFlags(..), emptyMakefileFlags,
> hunk ./Distribution/Setup.hs 62
> +                           parseMakefileArgs,
> hunk ./Distribution/Setup.hs 97
> +            | MakefileCmd             -- makefile
> hunk ./Distribution/Setup.hs 253
> +
> +data MakefileFlags = MakefileFlags {makefileVerbose :: Int,
> +                                    makefileFile :: Maybe FilePath}
> +    deriving Show
> +emptyMakefileFlags = MakefileFlags {makefileVerbose = 1,
> +                                    makefileFile = Nothing}
> +
> hunk ./Distribution/Setup.hs 263
> --- |Most of these flags are for Configure, but InstPrefix is for Copy.
> +-- | All the possible flags
> hunk ./Distribution/Setup.hs 302
> +          -- For makefile:
> +          | MakefileFile FilePath
> hunk ./Distribution/Setup.hs 391
> -commandList progConf = [(configureCmd progConf), buildCmd, cleanCmd, installCmd,
> +commandList progConf = [(configureCmd progConf), buildCmd, makefileCmd,
> +                        cleanCmd, installCmd,
> hunk ./Distribution/Setup.hs 609
> +makefileCmd :: Cmd a
> +makefileCmd = Cmd {
> +        cmdName        = "makefile",
> +        cmdHelp        = "Perform any necessary makefileing.",
> +        cmdDescription = "",  -- This can be a multi-line description
> +        cmdOptions     = [cmd_help, cmd_verbose,
> +           Option "f" ["file"] (reqPathArg MakefileFile)
> +               "Filename to use (default: Makefile)."],
> +        cmdAction      = MakefileCmd
> +        }
> +
> +parseMakefileArgs :: MakefileFlags -> [String] -> [OptDescr a] -> IO (MakefileFlags, [a], [String])
> +parseMakefileArgs = parseArgs makefileCmd updateCfg
> +  where updateCfg mflags fl =
> +           case fl of
> +                Verbose n      -> mflags{makefileVerbose=n}
> +                MakefileFile f -> mflags{makefileFile=Just f}
> +
> hunk ./Distribution/Simple/Build.hs 46
> -	build
> +	build, makefile
> hunk ./Distribution/Simple/Build.hs 58
> -import Distribution.Setup	 (CopyDest(..), BuildFlags(..) )
> +import Distribution.Setup	( CopyDest(..), BuildFlags(..), 
> +                                  MakefileFlags(..) )
> hunk ./Distribution/Simple/Build.hs 75
> -import Control.Monad 		( unless )
> +import Control.Monad 		( unless, when )
> hunk ./Distribution/Simple/Build.hs 92
> -build :: PackageDescription  -- ^mostly information from the .cabal file
> +build    :: PackageDescription  -- ^mostly information from the .cabal file
> hunk ./Distribution/Simple/Build.hs 98
> +  initialBuildSteps pkg_descr lbi verbose suffixes
> +  setupMessage verbose "Building" pkg_descr
> +  case compilerFlavor (compiler lbi) of
> +    GHC  -> GHC.build  pkg_descr lbi verbose
> +    JHC  -> JHC.build  pkg_descr lbi verbose
> +    Hugs -> Hugs.build pkg_descr lbi verbose
> +    _    -> die ("Building is not supported with this compiler.")
> +
> +makefile :: PackageDescription  -- ^mostly information from the .cabal file
> +         -> LocalBuildInfo -- ^Configuration information
> +         -> MakefileFlags -- ^Flags that the user passed to makefile
> +         -> [ PPSuffixHandler ] -- ^preprocessors to run before compiling
> +         -> IO ()
> +makefile pkg_descr lbi flags suffixes = do
> +  let verb = makefileVerbose flags
> +  initialBuildSteps pkg_descr lbi verb suffixes
> +  when (not (hasLibs pkg_descr)) $
> +      die ("Makefile is only supported for libraries, currently.")
> +  setupMessage verb "Generating Makefile" pkg_descr
> +  case compilerFlavor (compiler lbi) of
> +    GHC  -> GHC.makefile  pkg_descr lbi flags
> +    _    -> die ("Generating a Makefile is not supported for this compiler.")
> +
> +
> +initialBuildSteps pkg_descr lbi verbose suffixes = do
> hunk ./Distribution/Simple/Build.hs 138
> -  setupMessage verbose "Building" pkg_descr
> -  case compilerFlavor (compiler lbi) of
> -   GHC  -> GHC.build  pkg_descr lbi verbose
> -   JHC  -> JHC.build  pkg_descr lbi verbose
> -   Hugs -> Hugs.build pkg_descr lbi verbose
> -   _    -> die ("Building is not supported with this compiler.")
> hunk ./Distribution/Simple/GHC.hs 5
> --- Copyright   :  Isaac Jones 2003-2006
> +-- Copyright   :  Isaac Jones 2003-2007
> hunk ./Distribution/Simple/GHC.hs 47
> -	build, installLib, installExe
> +	build, makefile, installLib, installExe
> hunk ./Distribution/Simple/GHC.hs 50
> +import Distribution.Setup       ( MakefileFlags(..) )
> hunk ./Distribution/Simple/GHC.hs 90
> +import System.IO
> hunk ./Distribution/Simple/GHC.hs 355
> -     ++ (if compilerVersion (compiler lbi) > Version [6,4] []
> +     ++ ghcOptions lbi bi odir
> +
> +ghcOptions lbi bi odir
> +     =  (if compilerVersion (compiler lbi) > Version [6,4] []
> hunk ./Distribution/Simple/GHC.hs 378
> +-- -----------------------------------------------------------------------------
> +-- Building a Makefile
> +
> +makefile :: PackageDescription -> LocalBuildInfo -> MakefileFlags -> IO ()
> +makefile pkg_descr lbi flags = do
> +  let file = case makefileFile flags of
> +                Just f ->  f
> +                _otherwise -> "Makefile"
> +  h <- openFile file WriteMode
> +
> +  let Just lib = library pkg_descr
> +      bi = libBuildInfo lib
> +  
> +      ghc_vers = compilerVersion (compiler lbi)
> +      packageId | versionBranch ghc_vers >= [6,4]
> +                                = showPackageId (package pkg_descr)
> +                 | otherwise = pkgName (package pkg_descr)
> +  let decls = [
> +        ("modules", unwords (exposedModules lib ++ otherModules bi)),
> +        ("GHC", compilerPath (compiler lbi)),
> +        ("WAYS", if withProfLib lbi then "p" else ""),
> +        ("odir", buildDir lbi),
> +        ("package", packageId),
> +        ("GHC_OPTS", unwords (ghcOptions lbi bi (buildDir lbi))),
> +        ("MAKEFILE", file)
> +        ]
> +  hPutStrLn h (unlines (map (\(a,b)-> a ++ " = " ++ munge b) decls))
> +  hPutStrLn h makefileTemplate
> +  hClose h
> + where
> +  munge "" = ""
> +  munge ('#':s) = '\\':'#':munge s
> +  munge (c:s) = c : munge s
> +
> hunk ./Distribution/Simple/GHC.hs 497
> +-- -----------------------------------------------------------------------------
> +-- Makefile template
> +
> +makefileTemplate =
> + "GHC_OPTS += -package-name $(package) -i$(odir)\n"++
> + "\n"++
> + "# For adding options on the command-line\n"++
> + "GHC_OPTS += $(EXTRA_HC_OPTS)\n"++
> + "\n"++
> + "WAY_p_OPTS = -prof\n"++
> + "\n"++
> + "ifneq \"$(way)\" \"\"\n"++
> + "way_ := $(way)_\n"++
> + "_way := _$(way)\n"++
> + "GHC_OPTS += $(WAY_$(way)_OPTS)\n"++
> + "GHC_OPTS += -hisuf $(way_)hi -hcsuf $(way_)hc -osuf $(way_)o\n"++
> + "endif\n"++
> + "\n"++
> + "OBJS = $(patsubst %,$(odir)/%.$(way_)o,$(subst .,/,$(modules)))\n"++
> + "\n"++
> + "all :: .depend $(OBJS)\n"++
> + "\n"++
> + ".depend : $(MAKEFILE)\n"++
> + "	$(GHC) -M -optdep-f -optdep.depend $(foreach way,$(WAYS),-optdep-s -optdep$(way)) $(foreach obj,$(MKDEPENDHS_OBJ_SUFFICES),-osuf $(obj)) $(filter-out -split-objs, $(GHC_OPTS)) $(modules)\n"++
> + "	for dir in $(sort $(foreach mod,$(OBJS),$(dir $(mod)))); do \\\n"++
> + "		if test ! -d $$dir; then mkdir $$dir; fi \\\n"++
> + "	done\n"++
> + "\n"++
> + "include .depend\n"++
> + "\n"++
> + "# suffix rules\n"++
> + "\n"++
> + "ifneq \"$(odir)\" \"\"\n"++
> + "odir_ = $(odir)/\n"++
> + "else\n"++
> + "odir_ =\n"++
> + "endif\n"++
> + "\n"++
> + "$(odir_)%.$(way_)o : %.hs\n"++
> + "	$(GHC) $(GHC_OPTS) -c $< -o $@  -ohi $(basename $@).$(way_)hi\n"++
> + "\n"++
> + "$(odir_)%.$(way_)o : %.lhs	 \n"++
> + "	$(GHC) $(GHC_OPTS) -c $< -o $@  -ohi $(basename $@).$(way_)hi\n"++
> + "\n"++
> + "$(odir_)%.$(way_)o : %.c\n"++
> + "	@$(RM) $@\n"++
> + "	$(GHC) $(GHC_CC_OPTS) -c $< -o $@\n"++
> + "\n"++
> + "$(odir_)%.$(way_)o : %.$(way_)s\n"++
> + "	@$(RM) $@\n"++
> + "	$(GHC) $(GHC_CC_OPTS) -c $< -o $@\n"++
> + "\n"++
> + "$(odir_)%.$(way_)o : %.S\n"++
> + "	@$(RM) $@\n"++
> + "	$(GHC) $(GHC_CC_OPTS) -c $< -o $@\n"++
> + "\n"++
> + "$(odir_)%.$(way_)s : %.c\n"++
> + "	@$(RM) $@\n"++
> + "	$(GHC) $(GHC_CC_OPTS) -S $< -o $@\n"++
> + "\n"++
> + "%.$(way_)hi : %.$(way_)o\n"++
> + "	@if [ ! -f $@ ] ; then \\\n"++
> + "	    echo Panic! $< exists, but $@ does not.; \\\n"++
> + "	    exit 1; \\\n"++
> + "	else exit 0 ; \\\n"++
> + "	fi							\n"++
> + "\n"++
> + "%.$(way_)hi-boot : %.$(way_)o-boot\n"++
> + "	@if [ ! -f $@ ] ; then \\\n"++
> + "	    echo Panic! $< exists, but $@ does not.; \\\n"++
> + "	    exit 1; \\\n"++
> + "	else exit 0 ; \\\n"++
> + "	fi							\n"++
> + "\n"++
> + "$(odir_)%.$(way_)hi : %.$(way_)hc\n"++
> + "	@if [ ! -f $@ ] ; then \\\n"++
> + "	    echo Panic! $< exists, but $@ does not.; \\\n"++
> + "	    exit 1; \\\n"++
> + "	else exit 0 ; \\\n"++
> + "	fi\n"++
> + "\n"++
> + "show:\n"++
> + "	@echo '$(VALUE)=\"$($(VALUE))\"'\n"++
> + "\n"++
> + "\n"++
> + "ifneq \"$(strip $(WAYS))\" \"\"\n"++
> + "ifeq \"$(way)\" \"\"\n"++
> + "all ::\n"++
> + "# Don't rely on -e working, instead we check exit return codes from sub-makes.\n"++
> + "	@case '${MFLAGS}' in *-[ik]*) x_on_err=0;; *-r*[ik]*) x_on_err=0;; *) x_on_err=1;; esac; \\\n"++
> + "	for i in $(WAYS) ; do \\\n"++
> + "	  echo \"== $(MAKE) way=$$i -f $(MAKEFILE) $@;\"; \\\n"++
> + "	  $(MAKE) way=$$i -f $(MAKEFILE) --no-print-directory $(MFLAGS) $@ ; \\\n"++
> + "	  if [ $$? -eq 0 ] ; then true; else exit $$x_on_err; fi; \\\n"++
> + "	done\n"++
> + "	@echo \"== Finished recursively making \\`$@' for ways: $(WAYS) ...\"\n"++
> + "endif\n"++
> + "endif\n"++
> + "\n"++
> + "# We could consider adding this: the idea would be to have 'make' do\n"++
> + "# everything that 'setup build' does.\n"++
> + "# ifeq \"$(way)\" \"\"\n"++
> + "# all ::\n"++
> + "# 	./Setup build\n"++
> + "# endif\n"
> +
> hunk ./Distribution/Simple.hs 80
> -import Distribution.Simple.Build	( build )
> +import Distribution.Simple.Build	( build, makefile )
> hunk ./Distribution/Simple.hs 157
> +      -- |Hook to run before makefile command.  Second arg indicates verbosity level.
> +     preMakefile  :: Args -> MakefileFlags -> IO HookedBuildInfo,
> +
> +     -- |Over-ride this hook to gbet different behavior during makefile.
> +     makefileHook :: PackageDescription -> LocalBuildInfo -> Maybe UserHooks -> MakefileFlags -> IO (),
> +      -- |Hook to run after makefile command.  Second arg indicates verbosity level.
> +     postMakefile :: Args -> MakefileFlags -> PackageDescription -> LocalBuildInfo -> IO ExitCode,
> +
> hunk ./Distribution/Simple.hs 324
> +            MakefileCmd ->
> +                command (parseMakefileArgs emptyMakefileFlags) makefileVerbose
> +                        preMakefile makefileHook postMakefile
> +                        getPersistBuildConfig
> +        
> hunk ./Distribution/Simple.hs 603
> +       preMakefile = rn,
> +       makefileHook = ru,
> +       postMakefile = res,
> hunk ./Distribution/Simple.hs 642
> +       makefileHook = defaultMakefileHook,
> hunk ./Distribution/Simple.hs 675
> +       preMakefile = readHook makefileVerbose,
> hunk ./Distribution/Simple.hs 726
> +      writeInstalledConfig pkg_descr localbuildinfo False
> +
> +defaultMakefileHook :: PackageDescription -> LocalBuildInfo
> +	-> Maybe UserHooks -> MakefileFlags -> IO ()
> +defaultMakefileHook pkg_descr localbuildinfo hooks flags = do
> +  makefile pkg_descr localbuildinfo flags (allSuffixHandlers hooks)
> +  when (hasLibs pkg_descr) $
> hunk ./doc/Cabal.xml 1704
> +
> +    <sect2 id="setup-makefile">
> +      <title>setup makefile</title>
> +      <para>Generate a Makefile that may be used to compile the
> +      Haskell modules to object code.  This command is currently only
> +      supported when building libraries, and only if the compiler is
> +      GHC.</para>
> +
> +      <para>The makefile replaces part of the work done by
> +      <literal>setup build</literal>.  The sequence of commands would
> +      typeically be:
> +<programlisting>
> +runhaskell Setup.hs makefile
> +make
> +runhaskell Setup.hs build
> +</programlisting>
> +      where <literal>setup makefile</literal> does the preprocessing,
> +      <literal>make</literal> compiles the Haskell modules, and
> +      <literal>setup build</literal> performs any final steps, such as
> +      building the library archives.</para>
> +
> +      <para>The Makefile does not use GHC's <literal>--make</literal>
> +      flag to compile the modules, instead it compiles modules one at
> +      a time, using dependency information generated by GHC's
> +      <literal>-M</literal> flag.  There are two reasons you might
> +      therefore want to use <literal>setup makefile</literal>:
> +
> +      <itemizedlist>
> +        <listitem>
> +          <para>You want to build in parallel using <literal>make -j</literal>.
> +          Currently, <literal>setup build</literal> on its own does not support
> +          building in parallel.</para>
> +        </listitem>
> +        <listitem>
> +          <para>You want to build an individual module, pass extra
> +          flags to a compilation, or do other non-standard things that
> +          <literal>setup build</literal> does not support.</para>
> +        </listitem>
> +      </itemizedlist>
> +      </para>
> +
> +    </sect2>
> }
> 
> Context:
> 
> [add Distribution.SetupWrapper to exposed-modules
> Simon Marlow <simonmar@microsoft.com>**20070309122146] 
> [Tweaks to make Cabal play nicer with haddock
> Ian Lynagh <igloo@earth.li>**20070308155718
>  
>  The path for the html docs now includes the package name at the end,
>  which works nicer for multiple packages sharing a contents/index.
>  
>  Use --ghc-pkg when available (in haddock darcs only currently) to tell
>  haddock which ghc-pkg to use.
>  
>  Use --allow-missing-html when available (in haddock darcs only
>  currently) to tell haddock not to worry if it can't find the HTML for
>  packages we depend on. This is necessary when haddocking a group of
>  packages before moving them all into place.
> ] 
> [Cope with ghc-pkg telling us packages are broken
> Ian Lynagh <igloo@earth.li>**20070307193131] 
> [Tell GHC to use .hs mode when we want it to cpp something for us
> Ian Lynagh <igloo@earth.li>**20070307143612] 
> [Add parentheses so expressions are parsed correctly
> Ian Lynagh <igloo@earth.li>**20070307131941] 
> [minor refactoring
> Ross Paterson <ross@soi.city.ac.uk>**20070301002731] 
> [fix \begin{code typo
> Ross Paterson <ross@soi.city.ac.uk>**20070301002557] 
> [document the --with-compiler / --with-hc inconsistency
> Ross Paterson <ross@soi.city.ac.uk>**20070225115601] 
> [Clarify documentation on --with-compiler and --with-hc-pkg
> simonpj@microsoft.com**20070221110452] 
> [minor markup tweaks
> Ross Paterson <ross@soi.city.ac.uk>**20070218104622] 
> [This usePackages stuff is haddock-specific so name it as such
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20070213201434] 
> [{en,dis}able-use-packages, -optP-P only if haddock<0.8
> Conal Elliott <conal@conal.net>**20070204061106] 
> [cabal-upload: Added command-line options for username, password, checking instead of uploading. Added ability to get login from file, and to get password from the terminal. Added still unused verbosity options. Bumped version number to 0.2.
> bjorn@bringert.net**20070212232920] 
> [exclude Setup.lhs
> Ross Paterson <ross@soi.city.ac.uk>**20070212193608
>  
>  This was generating a useless Main entry in the lib doc index.
>  (good for STABLE)
> ] 
> [Add recent Cabal modules to nhc98 build system.
> Malcolm.Wallace@cs.york.ac.uk**20070212171106] 
> [Compatibility with Haskell'98.
> Malcolm.Wallace@cs.york.ac.uk**20070212170804
>  Import Distribution.Compat.Exception instead of Control.Exception.
>  Fix illegal indentation of cascaded do-blocks.
> ] 
> [add --enable-optimization/--disable-optimization config options (on by default)
> Ross Paterson <ross@soi.city.ac.uk>**20070212004513] 
> [cabal-upload: nicer output.
> bjorn@bringert.net**20070206154619] 
> [Send Accept header.
> bjorn@bringert.net**20070206153521] 
> [Allow uploading multiple packages.
> bjorn@bringert.net**20070206153406] 
> [Changed HTTP dependency to >= 1.0. 
> bjorn@bringert.net**20070206153054] 
> [cabal-upload: Removed build-simple since hackage doesn't seem to accept it for non-lib packages.
> bjorn@bringert.net**20070206133616] 
> [Added URL for cabal-upload wiki page.
> bjorn@bringert.net**20070206132142] 
> [Added usage message to cabal-upload.
> bjorn@bringert.net**20070206131408] 
> [Added a small hacky first version of cabal-upload.
> bjorn@bringert.net**20070206112237] 
> [cabal-setup doesn't need -cpp
> Ross Paterson <ross@soi.city.ac.uk>**20070115154724] 
> [Refactorings only
> Simon Marlow <simonmar@microsoft.com>**20070114203741
>  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.
> ] 
> [pass arguments through when performing the setup actions ourselves
> Ross Paterson <ross@soi.city.ac.uk>**20070113133211] 
> [separate option for the compiler for Setup.hs
> Ross Paterson <ross@soi.city.ac.uk>**20070113133000
>  
>  This need not be the same compiler as used to build the package
> ] 
> [Ignoring user packages when installing locally doesn't make sense.
> Lemmih <lemmih@gmail.com>**20070112150318] 
> [cabal-install now caches downloaded packages in the directory for the package, and with .tar.gz extension.
> bjorn@bringert.net**20070112143527] 
> [cabal-install.cabal: Added build-type field. Change hs-source-dir to hs-source-dirs (hs-source-dir has been deprecated for some time).
> bjorn@bringert.net**20070112131959] 
> [cabal-install --user now keeps package cache and package list in ~/.cabal-install
> bjorn@bringert.net**20070112131301] 
> [fix ghc-options (not a listField)
> bjorn@bringert.net**20070112124938] 
> [add a Build-Type field, and use it in setupWrapper
> Ross Paterson <ross@soi.city.ac.uk>**20070111233018
>  
>  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.
> ] 
> [remove a use of null+head
> Ross Paterson <ross@soi.city.ac.uk>**20070111182430] 
> [remove two fromJust's
> Ross Paterson <ross@soi.city.ac.uk>**20070111182401] 
> [pass CABAL_VERSION to Hugs
> Ross Paterson <ross@soi.city.ac.uk>**20070111182216] 
> [cabal-install now puts the package list in /var/lib/cabal-install and the tarballs in /var/cache/cabal-install by default. Added command-line options for changing those.
> bjorn@bringert.net**20070111190452] 
> [Track verbosity argument changes
> Ian Lynagh <igloo@earth.li>**20070111180601] 
> [Testsuite quietening
> Ian Lynagh <igloo@earth.li>**20070111175329] 
> [cabal-install: Output usage info for the right command when pasrsing the package name arguments fails.
> bjorn@bringert.net**20070111164924] 
> [SetupWrapper now passes verbosity to other functions, as required by Igloo's patch.
> bjorn@bringert.net**20070111161651] 
> [Make cabal-install use setupWrapper (the library version of cabal-setup).
> bjorn@bringert.net**20070111160535] 
> [Moved the cabal-setup code to Distribution.SetupWrapper, so that cabal-install can use it. CabalSetup.hs now just calls the setupWrapper function.
> bjorn@bringert.net**20070111130506] 
> [Quieten the testsuite more
> Ian Lynagh <igloo@earth.li>**20070111155957] 
> [Pass verbosity info down to warn
> Ian Lynagh <igloo@earth.li>**20070111154526] 
> [Derive Show on various datatypes
> Ian Lynagh <igloo@earth.li>**20070111140220] 
> [Give feedback in runTests.sh
> Ian Lynagh <igloo@earth.li>**20070111132654] 
> [Be less verbose at verbosity level 1
> Ian Lynagh <igloo@earth.li>**20070111131228] 
> [Fix warning
> Ian Lynagh <igloo@earth.li>**20070111130928] 
> [No need for -fno-warn-unused-matches any more
> Ian Lynagh <igloo@earth.li>**20070111130824] 
> [Always pass Hooks around, not Maybe Hooks
> Ian Lynagh <igloo@earth.li>**20070111124234] 
> [Make Makefile use the right ghc/ghc-pkg
> Ian Lynagh <igloo@earth.li>**20070111122833] 
> [Add -Wall to GHCFLAGS
> Ian Lynagh <igloo@earth.li>**20070111102742] 
> [Updated cabal-install test scripts to use the main Cabal repo.
> bjorn@bringert.net**20070111111727] 
> [Added cabal-install test scripts.
> bjorn@bringert.net**20070110184835] 
> [Added cabal-install Makefile.
> bjorn@bringert.net**20070110184754] 
> [Added HTTP package code used by cabal-install.
> bjorn@bringert.net**20070110184545] 
> [Imported all the cabal-install sources.
> bjorn@bringert.net**20070110183142] 
> [Added cabal-install dep on regex-compat.
> bjorn@bringert.net**20070110180020] 
> [Removed old CabalInstall.hs (it has moved to cabal-install/src in one of the pataches I pulled in).
> bjorn@bringert.net**20070110174435] 
> [Pulling in cabal-install: changed default Hackage DB URL.
> bjorn@bringert.net**20070110173825] 
> [Pulling cabal-with-install into Cabal: cabal-install.cabal changes.
> bjorn@bringert.net**20070110172811] 
> [Pulling changes from cabal-with-install: Multiple repositories.
> bjorn@bringert.net**20070110164852
>  Original patch:
>  Sat Sep  2 00:13:40 CEST 2006  Paolo Martini <paolo@nemail.it>
>    * Multiple repositories.
> ] 
> [Pulling changes from cabal-with-install: Stripping off the dependencies, only HTTP left
> bjorn@bringert.net**20070110164556
>  Original patch:
>  Sun Aug 20 19:01:03 CEST 2006  Paolo Martini <paolo@nemail.it>
>    * Stripping off the dependencies, only HTTP left
> ] 
> [Resolve Makefile conflict from importing Cabal-with-install patches.
> bjorn@bringert.net**20070110163852] 
> [a program to test download & install a bunch of cabal packages
> ijones@syntaxpolice.org**20061114063409] 
> [added --inplace trick to cabal build so that cabal-install can build on machines without cabal.
> ijones@syntaxpolice.org**20060922034620] 
> [First attempt to make a new repository (url in the configuration)
> Paolo Martini <paolo@nemail.it>**20060820180342] 
> [Tarball index format support
> Paolo Martini <paolo@nemail.it>**20060816223509] 
> [Quieten a test
> Ian Lynagh <igloo@earth.li>**20070110175223] 
> [Pass 0 verbosity on to GHC when building
> Ian Lynagh <igloo@earth.li>**20070110174050] 
> [More verbosity tweaking
> Ian Lynagh <igloo@earth.li>**20070110172956] 
> [Rejig verbosity levels a bit; 1 is now the default (was 0)
> Ian Lynagh <igloo@earth.li>**20070110165149] 
> [Make system tweaks to avoid cabal thinking it isn't bootstrapped when running the testsuite
> Ian Lynagh <igloo@earth.li>**20070110162940] 
> [Typo
> Ian Lynagh <igloo@earth.li>**20070110154617] 
> [Refer to the right variables
> Ian Lynagh <igloo@earth.li>**20070110151326] 
> [Give unrecognised flags more clearly
> Ian Lynagh <igloo@earth.li>**20070110144650] 
> [Beautify
> Ian Lynagh <igloo@earth.li>**20070110143711] 
> [Retab
> Ian Lynagh <igloo@earth.li>**20070110143103] 
> [Remove some chatter from the test scripts
> Ian Lynagh <igloo@earth.li>**20070110142756] 
> [Eliminate more warnings
> Ian Lynagh <igloo@earth.li>**20070110142114] 
> [More -Wall clean fixes
> Ian Lynagh <igloo@earth.li>**20070110135838] 
> [Improve cleaning
> Ian Lynagh <igloo@earth.li>**20070110134230] 
> [-Wall clean fixes
> Ian Lynagh <igloo@earth.li>**20070110125523
>  
>  This patch is sponsored by Hac 07.
>  Have you hacked a lambda today?
> ] 
> [Fix non-fatal problem with 'setup haddock' for an exe package
> Simon Marlow <simonmar@microsoft.com>**20070109133751
>  For some unknown reason, we were passing --use-package=P to haddock,
>  where P is the name of the current executable package.  This can never
>  work, since P is not a library and will not be installed.  Fortunately
>  Haddock ignores the error and continues anyway.
>  
> ] 
> [Set the Cabal version when building via the fptools build system
> sven.panne@aedion.de**20070106152814
>  
>  Without this patch, Cabal is effectively "version-less" and all .cabal
>  files with a version requirement are unusable. Therefore I think that
>  this patch (or at least something equivalent) should be pushed to the
>  6.6.1 branch, too.
> ] 
> [added --save-configure flag to clean. got some complaints that there was no way to avoid reconfiguring after a clean.  now if you use --save-configure, you should be able to.
> ijones@syntaxpolice.org**20061219152204] 
> [tiny mod to License comments
> ijones@syntaxpolice.org**20061219060021] 
> [improving help output
> ijones@syntaxpolice.org**20061219055849
>  As suggested by Claus Reinke in this ticket:
>  http://hackage.haskell.org/trac/hackage/ticket/105
> ] 
> [fix ./Setup unregister --help, which was giving the help for register
> Simon Marlow <simonmar@microsoft.com>**20061215165000] 
> [Fix the links in the user guide to the API docs
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>*-20061129131633] 
> [Fix the links in the user guide to the API docs
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061129131633] 
> [haddock comments for SrcDist.hs
> ijones@syntaxpolice.org**20061127041303] 
> [some haddock comments for LocalBuildInfo.hs
> ijones@syntaxpolice.org**20061127040916] 
> [a little comment for JHC.hs
> ijones@syntaxpolice.org**20061127040026] 
> [some comments for Install.hs
> ijones@syntaxpolice.org**20061127035919] 
> [some comments for Hugs.hs
> ijones@syntaxpolice.org**20061127035310] 
> [haddock comments for GHC and GHCPackageConig
> ijones@syntaxpolice.org**20061127034617] 
> [some comments for Configure.hs
> ijones@syntaxpolice.org**20061127033157] 
> [some comments for Build.hs
> ijones@syntaxpolice.org**20061127032409] 
> [minor comments and cleanup for Setup.hs
> ijones@syntaxpolice.org**20061127031744] 
> [some haddock explanation of preprocessors
> ijones@syntaxpolice.org**20061127031055] 
> [some comments for Package.hs
> ijones@syntaxpolice.org**20061127025108] 
> [haddockizing some comments from Make.hs
> ijones@syntaxpolice.org**20061127024142] 
> [adding comments to Program.hs
> ijones@syntaxpolice.org**20061127022353] 
> [comments for the Program module
> ijones@syntaxpolice.org**20061127002749] 
> [don't return an error code just because there's no library to register
> ijones@syntaxpolice.org**20061124144831] 
> [Purely cosmetic; have '--<FOO>-args' use ARGS on their RHS rather than PATH in usage output
> sof@galois.com**20061121195844] 
> [parse executable field as a token (as documented), rather than free text
> Ross Paterson <ross@soi.city.ac.uk>**20061120093400] 
> [trim trailing spaces (including CRs) from all input lines
> Ross Paterson <ross@soi.city.ac.uk>**20061120092526] 
> [help nhc98 find the import of programLocation
> Malcolm.Wallace@cs.york.ac.uk**20061117144001] 
> [sdist: make it work on Windows platforms by simplifying 'tar' invocation. Hopefully not at the cost of other plats (i.e., as-yet untested there..)"
> sof@galois.com**20061117014832] 
> [build: consult and use any user-provided settings for 'ld' and 'ar'
> sof@galois.com**20061117014622] 
> [defaultUserHooks.sDistHook: pass in optional LBI to SrcDist.sdist
> sof@galois.com**20061117014448] 
> [defaultProgramConfiguration: add 'ld' and 'tar' entries
> sof@galois.com**20061117014318] 
> [revise Paths module for the Hugs target
> Ross Paterson <ross@soi.city.ac.uk>**20061108223349
>  
>  When targetting Hugs, the Paths module now uses prefix-independent
>  paths relative to the location of the Main module of the program,
>  on all platforms.
>  
>  For the Hugs target, this replaces the code using GetModuleFileNameA(),
>  which never worked.  Behaviour under GHC should be unchanged.
> ] 
> [Hugs: fix location of installed package info
> Ross Paterson <ross@soi.city.ac.uk>**20061021144613] 
> [Fix escaping of ' chars in register.sh script.
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061016215459] 
> [Tidy up command comments
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061013211158] 
> [Fix getDataDir etc. when bindir=$prefix
> Simon Marlow <simonmar@microsoft.com>**20061013100941] 
> [Update text on the front page: packages can now overlap in GHC 6.6
> Simon Marlow <simonmar@microsoft.com>**20061012114601
>  
> ] 
> [New unlit code "ported" from cpphs-1.2
> Lennart Kolmodin <kolmodin@dtek.chalmers.se>**20061009192609] 
> [Share one more place where the cabal version is defined.
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010140027] 
> [Fix spelling error in error message.
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010140013] 
> [Centeralise the places that know that Cabal version number
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010135918] 
> [Remove spurious debug message.
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010125643] 
> [Bump to next unstable development version
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010125602] 
> [Make cabal know it's own version number correctly
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010130939
>  This is an unpleasent way of doing it.
>  Will have to fix once and for all in the next version.
> ] 
> [TAG 1.1.6
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061009123801] 
> Patch bundle hash:
> 343e137602e63baf88fb7c8cd0c5feac7c76d623
> _______________________________________________
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel

From igloo at earth.li  Sun Mar 11 18:40:21 2007
From: igloo at earth.li (Ian Lynagh)
Date: Sun Mar 11 18:33:10 2007
Subject: branches and merging
In-Reply-To: <45F18D4C.8070309@gmail.com>
References: <45F18D4C.8070309@gmail.com>
Message-ID: <20070311224021.GA31912@matrix.chaos.earth.li>

On Fri, Mar 09, 2007 at 04:37:32PM +0000, Simon Marlow wrote:
> Cabal has the following branches:
> 
>  HEAD, in darcs.haskell.org:/cabal, used by GHC HEAD
>  1.1.6, in darcs.haskell.org/cabal-branches/cabal-1.1.6
>  GHC 6.6 branch, in darcs.haskell.org/ghc-6.6/packages/Cabal
> 
> The official 1.1.6 is diverging from GHC's 6.6 version.  We should merge 
> the two - Duncan would you like to take a look and see if you can pull from 
> GHC's branch into 1.1.6, and then we can use 1.1.6 in GHC 6.6?
> 
> Also I just noticed that Ross's patch
> 
> Mon Nov 20 09:25:26 GMT 2006  Ross Paterson <ross@soi.city.ac.uk>
>   * trim trailing spaces (including CRs) from all input lines
> 
> fixes #117 http://hackage.haskell.org/trac/hackage/ticket/117, and could 
> easily be merged into 1.1.6.

This one sounds like it should be merged too:

-----------------------
Sat Jan  6 07:28:14 PST 2007  sven.panne@aedion.de
  * Set the Cabal version when building via the fptools build system

  Without this patch, Cabal is effectively "version-less" and all .cabal
  files with a version requirement are unusable. Therefore I think that
  this patch (or at least something equivalent) should be pushed to the
  6.6.1 branch, too.

    M ./Makefile -1 +2
-----------------------


Thanks
Ian

From ahanwadi at gmail.com  Mon Mar 12 01:43:00 2007
From: ahanwadi at gmail.com (Ashish Hanwadikar)
Date: Mon Mar 12 02:57:55 2007
Subject: Why is there a cabal file at all?
References: <20070110022530.GB29286@gmx.de>
Message-ID: <loom.20070312T063652-232@post.gmane.org>

Marc Weber <marco-oweber <at> gmx.de> writes:
> 	addDependencies = case stringOption "pretty_print_lib" of
> 
> This should use the correct dependency if the option has already been set by
> cmdline or config file else ask the user or choose the first but noticing the
> user by printing a message like this:
> 
> 	unset option "pretty_print_lib", defaulting to "A"
> 
> preprocess should be passed all configuration options and return a list of 
source files,
> build should get the list of source file and return a list of executables
> which are installed by install
> Marc
> 

I like your idea. I had thought about something similar. See this post 
(http://ashish.typepad.com/ashishs_niti/2007/03/learning_haskel.html).

I have put up a Haskell project for Google Summer of Code 2007. I would love to 
work on this or related idea.



From marco-oweber at gmx.de  Mon Mar 12 07:53:23 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Mon Mar 12 06:46:16 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <loom.20070312T063652-232@post.gmane.org>
References: <20070110022530.GB29286@gmx.de>
	<loom.20070312T063652-232@post.gmane.org>
Message-ID: <20070312115323.GA10145@gmx.de>

On Mon, Mar 12, 2007 at 05:43:00AM +0000, Ashish Hanwadikar wrote:
> Marc Weber <marco-oweber <at> gmx.de> writes:
> > 	addDependencies = case stringOption "pretty_print_lib" of
> > 
> > This should use the correct dependency if the option has already been set by
> > cmdline or config file else ask the user or choose the first but noticing the
> > user by printing a message like this:
> > 
> > 	unset option "pretty_print_lib", defaulting to "A"
> > 
> > preprocess should be passed all configuration options and return a list of 
> source files,
> > build should get the list of source file and return a list of executables
> > which are installed by install
> > Marc
> > 
> 
> I like your idea. I had thought about something similar. See this post 
> (http://ashish.typepad.com/ashishs_niti/2007/03/learning_haskel.html).
> 
> I have put up a Haskell project for Google Summer of Code 2007. I would love to 
> work on this or related idea.

Hi Ashish Hanwadikar!

Have also a look at this project (Duncan has pointed me to it in a previous
post (" debugging support - multidimensional package selection ... ") on this
list).. I hadn't had enough to time to learn it thoroughly but it looks really
promising. Its task is not to build a haskell application, but to manage
dependencies and ensure that they are installed by their own installers (make,
scons, whatsover) a little bit like the portage system of gentoo but it seems
to be much faster. You can also have installed arbitrary amounts of the same
application differing only in the version..

quote Duncan:

" For some related work you might want to look at Nix:
http://www.cs.uu.nl/~eelco/pubs/ "

I have put some effort into my approach and my project can build ghc
executables now, read options from config files. The main advantage over cabal
is this general concept of a package:

data Package = Package { metaInfo :: MetaInfo
		       , actions :: Actions
		       }


type Actions = [(String, Action)]

data Action = Action {  -- on which actions does this action depend? 
		       actionDependencies :: [ String ]
		     , buildDependencies :: CheckedDeps
		     , runDependencies :: CheckedDeps
		     , checkRerun :: CheckRerun 
		     , actionToRun :: ExecutionMonad ActionResult
		     }

Especially for haskell the actions look like this:

             Pkg (HPS.Lang.Haskell.metaInfo hac) $ [  -- these actions will be availible
		   ( "listSourceFiles", empty { 
			   actionToRun = let list = showModules ms
					 in do liftIO $ putStrLn list
					       return $ ActionResult list
			   } ) -- this is needed by IDEs ?
		 , ( "compile", empty { 
			   actionToRun = compile'
			   } )
		 , ( "install", empty {
			   actionToRun = install'
			 , actionDependencies = ["compile"]

			 } )
		     -- , haddock to be implemented
		     -- , bindist -- binary distribution
		     -- , dist -- disribution of source files (in general only preprocessed files are included here ?)
		     -- , clean
		     ]


Note that the action "install" depends on "compile"
and compile will depend on "preprocess" which in turn will depend on "get
sources" or something similar.
A big advantage is that you can add new acitons running configure/make, building preprocessors, running/ building test applications etc. Of course this all is possible using cabal, too. But you have to use hooks which might give you some troubles if you want to build your package in a non standard way (eg wxhaskell, ghc itself? (multistage build), hdirect (two stage build if you need com support on windows))

Drawaback: Needs recent ghc version, a modified DrIft Preprocessor and HList.
I didn't konw how to put definitions in different modules because of mutable recursive dependecies.
Do pretty much seems to be in one file ;)

The 'dependency' analysis of those actions is done in one line:
      (concatMap (reverse . concat . levels) . dfs (graph ag)) idxs

which takes the build graph and finds all dependencies ;)

I've stopped working on it because I think nix does solve many issues I want to
have in a much better way such as installing arbitrary software packages. But I
need to learn more about it before I do know how to proceed.

So at the moment I think I need another build tool but no longer another
cross-platform packaging tool.

I'd like to share my work but I'm not sure wether its worth sharing

Marc
From ahanwadi at gmail.com  Mon Mar 12 12:43:22 2007
From: ahanwadi at gmail.com (Ashish Hanwadikar)
Date: Mon Mar 12 12:44:03 2007
Subject: Why is there a cabal file at all?
References: <20070110022530.GB29286@gmx.de>
	<loom.20070312T063652-232@post.gmane.org>
	<20070312115323.GA10145@gmx.de>
Message-ID: <loom.20070312T174032-926@post.gmane.org>

Marc Weber <marco-oweber <at> gmx.de> writes:

> have in a much better way such as installing arbitrary software packages. But 
I
> need to learn more about it before I do know how to proceed.
> 
> So at the moment I think I need another build tool but no longer another
> cross-platform packaging tool.
> 
> I'd like to share my work but I'm not sure wether its worth sharing
> 
> Marc
> 

Thanks for the quick reply. I think the nix system is a pretty good system. I 
will try it out further. Thanks for the info.
Ashish



From judah.jacobson at gmail.com  Tue Mar 13 21:47:36 2007
From: judah.jacobson at gmail.com (Judah Jacobson)
Date: Tue Mar 13 21:47:35 2007
Subject: darcs patch: Fix profiling executable with template haskell
Message-ID: <6d74b0d20703131847i33dc926cwc309a24970c0d6d8@mail.gmail.com>

Attached is a patch to fix a bug that I found when trying to compile
an executable for profiling with ghc  when my modules used template
haskell.

Cabal is smart enough already to accomodate TH by compiling everything
twice (first the regular way, then with profiling).  However, the
second compile is missing ghc's -osuf and -hisuf arguments (as in the
GHC manual, section 7.6.4).  This patch adds those arguments at the
right time; I've tested it against my own repositories and it seems to
work fine.

Best,
-Judah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: th-prof.patch
Type: application/octet-stream
Size: 16315 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070313/f64dc23b/th-prof-0001.obj
From simonmarhaskell at gmail.com  Wed Mar 14 08:29:09 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Wed Mar 14 08:29:11 2007
Subject: darcs patch: setup makefile
In-Reply-To: <1173542208.1018.725.camel@localhost>
References: <45F18656.9020104@gmail.com> <1173542208.1018.725.camel@localhost>
Message-ID: <45F7EA95.3030004@gmail.com>

Duncan Coutts wrote:

> Ultimately I'd like to cabal do the dependency analysis, be able to
> rebuild any module (not just the lib/prog target) and do things like
> parallel builds.
> 
> I'm well aware however that no one has the time at the moment to address
> that.

Sure, all I did was take a little shortcut using existing tools (ghc -M, GNU 
make).  These tools are not necessarily universally available, so you don't want 
to rely on this for a Cabal package.  In the situation I'm interested in 
(building GHC) we definitely do have GHC and GNU make, so 'setup makefile' makes 
complete sense.

There's one other thing I forgot to mention: currently GHC has a bug that 
prevents it from building itself with --make and -O (this bug I think: 
http://hackage.haskell.org/trac/ghc/ticket/445).  So 'setup makefile' lets us 
build GHC itself using Cabal, where we couldn't previously, and hence we'll be 
able to finally ditch all the horrible makefile code for building packages in 
GHC's build system.

Cheers,
	Simon


From bos at serpentine.com  Fri Mar 16 13:30:34 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Fri Mar 16 13:28:13 2007
Subject: Automatically running autoreconf?
Message-ID: <45FAD43A.3070709@serpentine.com>

The fact that most packages don't have autoconf encumbrances means that 
I almost inevitably forget to run autoreconf before building a package, 
which regularly leads to heartburn on my part.

It seems to me that it would be useful if "build" ran autoreconf if 
necessary.  If this seems sane, I would be happy to cook up a patch. 
What do people think?

	<b
From bos at serpentine.com  Fri Mar 16 13:31:22 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Fri Mar 16 13:29:00 2007
Subject: Automatically running autoreconf?
In-Reply-To: <45FAD43A.3070709@serpentine.com>
References: <45FAD43A.3070709@serpentine.com>
Message-ID: <45FAD46A.1090304@serpentine.com>

Bryan O'Sullivan wrote:

> It seems to me that it would be useful if "build" ran autoreconf if 
> necessary.

Of course, it would be "configure" that would need to run it, not 
"build".  You'd think I'd learn after tripping over this repeatedly.

	<b
From igloo at earth.li  Fri Mar 23 17:13:19 2007
From: igloo at earth.li (Ian Lynagh)
Date: Fri Mar 23 17:12:46 2007
Subject: Extensions and Cabal
Message-ID: <20070323211319.GA25984@matrix.chaos.earth.li>


Hi Cabalites,

I fear this may be contentious, but here goes anyway...

Currently we have (at least) 4 ways that extension E can be enabled for a
given file in a cabal package (using GHC as an example, if -fe enables E):

1. foo.cabal: Extensions: E
2. foo.cabal: Ghc-Options: -fe
3. Foo.hs: {-# LANGUAGE E #-}
4. Foo.hs: {-# OPTIONS_GHC -fe #-}

Ideally, from cabal's point of view, we would use option 1. This way
cabal knows about the extensions, so can fail early if we don't support
the necessary extensions to build something.

2 and 4 are inferior variants of 1 and 3 respectively; the only case I
can think of where you might want to use them is if cabal doesn't know
about the extension yet. This could be solved by a --language=E flag
that GHC treats identically to -fe. Obviously cabal can't check that GHC
supports this extension in advance (so would have to assume that it
does), but at least we no longer have any need to enable extensions with
method 2 or 4. We could also then have Cabal always pass a
--no-extension-flags flag, which would mean that GHC would reject -fe.

That wasn't the contentious bit, so hopefully you aren't too inflamed
yet!

Suppose we agree that we should only use method 1; there are a number of
issues:

* If someone uses method 3, no alarm bells will sound. The package will
  continue to build where it can be built.

* The same set of extensions is used for every module. For example, if
  you want to allow overlapping instances in one particular place[1]
  then you must allow them everywhere.

* If you want to load one of the modules in ghci, say, then you need to
  tell it what flags to use.

Thus I propose that the .cabal file actually specifies what extensions
the modules are /allowed/ to use, but does not actually enable them.
They would then be enabled by LANGUAGE pragmas in the modules as
necessary. So, if the .cabal file says "Extensions: E, F" then the
modules will be compiled with
    --no-extension-flags --allowed-extension=E,F
and if a module has "{-# LANGUAGE E #-}" then only extension E would be
enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then
compilation would fail as extension G is not permitted.

Any comments? Criticisms? Flames?


Thanks
Ian

[1] Currently we can only specify this to a file-level granularity, but
    in principle you could imagine more localised pragmas, like we have
    for unboxed fields.

From ndmitchell at gmail.com  Fri Mar 23 17:42:36 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri Mar 23 17:42:02 2007
Subject: Extensions and Cabal
In-Reply-To: <20070323211319.GA25984@matrix.chaos.earth.li>
References: <20070323211319.GA25984@matrix.chaos.earth.li>
Message-ID: <404396ef0703231442u5d272110vca04ce83f21af44@mail.gmail.com>

Hi

> Thus I propose that the .cabal file actually specifies what extensions
> the modules are /allowed/ to use, but does not actually enable them.
> They would then be enabled by LANGUAGE pragmas in the modules as
> necessary. So, if the .cabal file says "Extensions: E, F" then the
> modules will be compiled with
>     --no-extension-flags --allowed-extension=E,F
> and if a module has "{-# LANGUAGE E #-}" then only extension E would be
> enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then
> compilation would fail as extension G is not permitted.
>
> Any comments? Criticisms? Flames?

I like it!

> * If you want to load one of the modules in ghci, say, then you need to
>   tell it what flags to use.

I think this is the killer reason.

Another reason that you don't mention is that it discourages the use
of extensions, not massively, but slightly. Now if you want to use a
particular extension lots you must specify it in every single file.

Thanks

Neil
From duncan.coutts at worc.ox.ac.uk  Fri Mar 23 20:47:45 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Fri Mar 23 20:47:16 2007
Subject: Extensions and Cabal
In-Reply-To: <404396ef0703231442u5d272110vca04ce83f21af44@mail.gmail.com>
References: <20070323211319.GA25984@matrix.chaos.earth.li>
	<404396ef0703231442u5d272110vca04ce83f21af44@mail.gmail.com>
Message-ID: <1174697266.5066.7.camel@localhost>

On Fri, 2007-03-23 at 21:42 +0000, Neil Mitchell wrote:
> > Thus I propose that the .cabal file actually specifies what extensions
> > the modules are /allowed/ to use, but does not actually enable them.
> > They would then be enabled by LANGUAGE pragmas in the modules as
> > necessary. So, if the .cabal file says "Extensions: E, F" then the
> > modules will be compiled with
> >     --no-extension-flags --allowed-extension=E,F
> > and if a module has "{-# LANGUAGE E #-}" then only extension E would be
> > enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then
> > compilation would fail as extension G is not permitted.
> >
> > Any comments? Criticisms? Flames?
> 
> I like it!

So do I.

> > * If you want to load one of the modules in ghci, say, then you need to
> >   tell it what flags to use.
> 
> I think this is the killer reason.

That would be helpful.

See also Alexander Jacobson's recent email on this topic:

http://www.haskell.org/pipermail/haskell/2007-March/019265.html

> Another reason that you don't mention is that it discourages the use
> of extensions, not massively, but slightly. Now if you want to use a
> particular extension lots you must specify it in every single file.

Obviously it'd be easier on users / developers if Cabal could tell you
if you need to add extra allowed extensions that you're using. For that
we need to scan the .hs files, which probably means we need the full dep
analysis too.


Duncan

From bringert at cs.chalmers.se  Sat Mar 24 07:01:56 2007
From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=)
Date: Sat Mar 24 06:59:36 2007
Subject: SoC proposal: Implement Cabal configurations
Message-ID: <46050524.8070307@cs.chalmers.se>

I want Cabal configurations, so I added a SoC proposal for it, see 
http://hackage.haskell.org/trac/summer-of-code/ticket/1131

This was the latest spec I could find: 
http://www.mail-archive.com/cabal-devel@haskell.org/msg00282.html

I haven't taken part much in the configurations discussions, so I'm not 
sure how finished the spec is or if it would be a good SoC project. Feel 
free to comment on / change the proposal as you see fit.

/Bj?rn
From kolmodin at dtek.chalmers.se  Sat Mar 24 08:03:21 2007
From: kolmodin at dtek.chalmers.se (Lennart Kolmodin)
Date: Sat Mar 24 08:02:45 2007
Subject: Extensions and Cabal
In-Reply-To: <20070323211319.GA25984@matrix.chaos.earth.li>
References: <20070323211319.GA25984@matrix.chaos.earth.li>
Message-ID: <46051389.8030700@dtek.chalmers.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Lynagh wrote:

> * The same set of extensions is used for every module. For example, if
>   you want to allow overlapping instances in one particular place[1]
>   then you must allow them everywhere.

You explicitly have to add potentially dangerous extensions when you
need them, that would be a gain, the downside being that you actually
have to write them...

> * If you want to load one of the modules in ghci, say, then you need to
>   tell it what flags to use.

It's more or less this that raised this question at all. Big gain if you
didn't have to.

> Thus I propose that the .cabal file actually specifies what extensions
> the modules are /allowed/ to use, but does not actually enable them.
> They would then be enabled by LANGUAGE pragmas in the modules as
> necessary. So, if the .cabal file says "Extensions: E, F" then the
> modules will be compiled with
>     --no-extension-flags --allowed-extension=E,F
> and if a module has "{-# LANGUAGE E #-}" then only extension E would be
> enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then
> compilation would fail as extension G is not permitted.
> 
> Any comments? Criticisms? Flames?

Yes! It's a compiler independent way of adding extensions, yet the
control of what can be used is maintained by Cabal.

There will be a phase when many cabal projects has to be adapted, but it
might just be worth it.

I like it a lot, thanks Ian!

Cheers,
  Lennart Kolmodin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGBROJ4txYG4KUCuERAhgSAKC0vYn1QnbvlxGu7raliWCXup2y9QCdEZTv
8lubE63mxDkZ2Guwyg8Vlrk=
=hTWC
-----END PGP SIGNATURE-----
From naesten at gmail.com  Sat Mar 24 18:53:54 2007
From: naesten at gmail.com (Samuel Bronson)
Date: Sat Mar 24 18:59:37 2007
Subject: Extensions and Cabal
References: <20070323211319.GA25984@matrix.chaos.earth.li>
Message-ID: <loom.20070324T234847-646@post.gmane.org>

Ian Lynagh <igloo <at> earth.li> writes:

> Thus I propose that the .cabal file actually specifies what extensions
> the modules are /allowed/ to use, but does not actually enable them.
> They would then be enabled by LANGUAGE pragmas in the modules as
> necessary. So, if the .cabal file says "Extensions: E, F" then the
> modules will be compiled with
>     --no-extension-flags --allowed-extension=E,F
> and if a module has "{-# LANGUAGE E #-}" then only extension E would be
> enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then
> compilation would fail as extension G is not permitted.
> 
> Any comments? Criticisms? Flames?

The only thing I can think of (besides "nice idea") is that you'd better either
 a) make sure that Cabal always knows about all the extensions supported by the
compiler
or
 b) provide a workaround for when Cabal does not know about a given extension.

From stefanor at cox.net  Sat Mar 24 19:14:24 2007
From: stefanor at cox.net (Stefan O'Rear)
Date: Sat Mar 24 19:13:47 2007
Subject: Extensions and Cabal
In-Reply-To: <loom.20070324T234847-646@post.gmane.org>
References: <20070323211319.GA25984@matrix.chaos.earth.li>
	<loom.20070324T234847-646@post.gmane.org>
Message-ID: <20070324231424.GA4167@localhost.localdomain>

On Sat, Mar 24, 2007 at 10:53:54PM +0000, Samuel Bronson wrote:
> Ian Lynagh <igloo <at> earth.li> writes:
> 
> > Thus I propose that the .cabal file actually specifies what extensions
> > the modules are /allowed/ to use, but does not actually enable them.
> > They would then be enabled by LANGUAGE pragmas in the modules as
> > necessary. So, if the .cabal file says "Extensions: E, F" then the
> > modules will be compiled with
> >     --no-extension-flags --allowed-extension=E,F
> > and if a module has "{-# LANGUAGE E #-}" then only extension E would be
> > enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then
> > compilation would fail as extension G is not permitted.
> > 
> > Any comments? Criticisms? Flames?
> 
> The only thing I can think of (besides "nice idea") is that you'd better either
>  a) make sure that Cabal always knows about all the extensions supported by the
> compiler
> or
>  b) provide a workaround for when Cabal does not know about a given extension.

We already have this, it's called darcs send.

That said, cabal is very sorely lacking hacker's documentation.  I for
one can't understand the code.  (yet (but still I learned lambdabot
faster))

Stefan
From igloo at earth.li  Sat Mar 24 19:24:00 2007
From: igloo at earth.li (Ian Lynagh)
Date: Sat Mar 24 19:23:23 2007
Subject: Extensions and Cabal
In-Reply-To: <loom.20070324T234847-646@post.gmane.org>
References: <20070323211319.GA25984@matrix.chaos.earth.li>
	<loom.20070324T234847-646@post.gmane.org>
Message-ID: <20070324232400.GA30965@matrix.chaos.earth.li>

On Sat, Mar 24, 2007 at 10:53:54PM +0000, Samuel Bronson wrote:
> Ian Lynagh <igloo <at> earth.li> writes:
> 
> > Thus I propose that the .cabal file actually specifies what extensions
> > the modules are /allowed/ to use, but does not actually enable them.
> > They would then be enabled by LANGUAGE pragmas in the modules as
> > necessary. So, if the .cabal file says "Extensions: E, F" then the
> > modules will be compiled with
> >     --no-extension-flags --allowed-extension=E,F
> > and if a module has "{-# LANGUAGE E #-}" then only extension E would be
> > enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then
> > compilation would fail as extension G is not permitted.
> > 
> > Any comments? Criticisms? Flames?
> 
> The only thing I can think of (besides "nice idea") is that you'd better either
>  a) make sure that Cabal always knows about all the extensions supported by the
> compiler
> or
>  b) provide a workaround for when Cabal does not know about a given extension.

That's the --language=E flag in the paragraph beginning "2 and 4".

But actually, Cabal would no longer enable extensions with this flag
anyway, it would just list the extensions after the --allowed-extension
flag (and it doesn't need to recognise them to list them).


Thanks
Ian

From stefanor at cox.net  Sat Mar 24 19:39:23 2007
From: stefanor at cox.net (Stefan O'Rear)
Date: Sat Mar 24 19:38:50 2007
Subject: Extensions and Cabal
In-Reply-To: <db65a1cd0703241629x343523bbn3563787cdafa447a@mail.gmail.com>
References: <20070323211319.GA25984@matrix.chaos.earth.li>
	<loom.20070324T234847-646@post.gmane.org>
	<20070324231424.GA4167@localhost.localdomain>
	<db65a1cd0703241629x343523bbn3563787cdafa447a@mail.gmail.com>
Message-ID: <20070324233923.GA5474@localhost.localdomain>

On Sat, Mar 24, 2007 at 06:29:56PM -0500, Samuel Bronson wrote:
> On 3/24/07, Stefan O'Rear <stefanor@cox.net> wrote:
> 
> >> The only thing I can think of (besides "nice idea") is that you'd better 
> >either
> >>  a) make sure that Cabal always knows about all the extensions supported 
> >by the
> >> compiler
> >> or
> >>  b) provide a workaround for when Cabal does not know about a given 
> >extension.
> >
> >We already have this, it's called darcs send.
> >
> >That said, cabal is very sorely lacking hacker's documentation.  I for
> >one can't understand the code.  (yet (but still I learned lambdabot
> >faster))
> 
> So, how do you compel the people who do compiler releases to ensure
> that it is *done*?
>
> Also, what about the part where you have to wait for another Cabal
> release?

I was going to write a nice rebuttal here, but then I remembered I
hadn't read the original message well enough.  Having done so, I agree
with Ian completely.  (*Great* idea, I had the same one for the hv
system.)

Stefan
From bos at serpentine.com  Mon Mar 26 19:32:36 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Mon Mar 26 19:29:33 2007
Subject: Cabal and RPM redux
Message-ID: <46085814.2010108@serpentine.com>

Since my last attempt to add RPM support didn't go anywhere, I'd like to 
figure out what's a good way to make progress.

If I were to contribute a standalone program called cabal-rpm (just as 
cabal-install is a standalone program), would that be acceptable to add 
to the darcs repo?

	<b
From bos at serpentine.com  Mon Mar 26 19:44:02 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Mon Mar 26 19:40:59 2007
Subject: [PATCH] Check the exit code from tar
Message-ID: <46085AC2.5020702@serpentine.com>

Prior to this change, if tar failed, the sdist command would fail to notice.

	<b
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tar.patch
Type: text/x-patch
Size: 16941 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070326/29928e88/tar.bin
From igloo at earth.li  Mon Mar 26 20:42:09 2007
From: igloo at earth.li (Ian Lynagh)
Date: Mon Mar 26 20:41:28 2007
Subject: Cabal and RPM redux
In-Reply-To: <46085814.2010108@serpentine.com>
References: <46085814.2010108@serpentine.com>
Message-ID: <20070327004209.GA2944@matrix.chaos.earth.li>

On Mon, Mar 26, 2007 at 04:32:36PM -0700, Bryan O'Sullivan wrote:
> Since my last attempt to add RPM support didn't go anywhere, I'd like to 
> figure out what's a good way to make progress.
> 
> If I were to contribute a standalone program called cabal-rpm (just as 
> cabal-install is a standalone program), would that be acceptable to add 
> to the darcs repo?

I keep meaning to speak to Duncan about whether we can put cabal-install
(and any others) into its own repo. Duncan?

The current source arrangement is a little odd, and I think Simon
Marlow, Duncan and I agreed that cabal-install shouldn't come with a
minimal GHC (as it would pull in things like HTTP, FTP, SSL, ...
libraries, either now or in the future) while a minimal GHC has to
include Cabal.

I'd still expect cabal-install to come with the Windows install, Linux
bindists etc. Package-based distributions wouldn't need to include it
with GHC as there's no bootstrapping issue.


So in answer to your actual question, personally I think cabal-rpm
should be in its own package.


Thanks
Ian

From duncan.coutts at worc.ox.ac.uk  Mon Mar 26 23:06:41 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Mar 27 01:52:24 2007
Subject: Cabal and RPM redux
In-Reply-To: <20070327004209.GA2944@matrix.chaos.earth.li>
References: <46085814.2010108@serpentine.com>
	<20070327004209.GA2944@matrix.chaos.earth.li>
Message-ID: <1174964801.5035.16.camel@localhost>

On Tue, 2007-03-27 at 01:42 +0100, Ian Lynagh wrote:
> On Mon, Mar 26, 2007 at 04:32:36PM -0700, Bryan O'Sullivan wrote:
> > Since my last attempt to add RPM support didn't go anywhere, I'd like to 
> > figure out what's a good way to make progress.
> > 
> > If I were to contribute a standalone program called cabal-rpm (just as 
> > cabal-install is a standalone program), would that be acceptable to add 
> > to the darcs repo?
> 
> I keep meaning to speak to Duncan about whether we can put cabal-install
> (and any others) into its own repo. Duncan?
> 
> The current source arrangement is a little odd, and I think Simon
> Marlow, Duncan and I agreed that cabal-install shouldn't come with a
> minimal GHC (as it would pull in things like HTTP, FTP, SSL, ...
> libraries, either now or in the future) while a minimal GHC has to
> include Cabal.

Right, so long as when clueless people/students download ghc it has all
that they need to get going with installing things from hackage then
it's all ok. So if that means a slightly fatter ghc bindist that
includes Cabal + cabal-install then yeah fine.

As you say, distros can sort themselves out and have minimal ghc and
cabal-install as separate packages.

Duncan

From bos at serpentine.com  Tue Mar 27 02:16:57 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue Mar 27 02:16:12 2007
Subject: Cabal and RPM redux
In-Reply-To: <20070327004209.GA2944@matrix.chaos.earth.li>
References: <46085814.2010108@serpentine.com>
	<20070327004209.GA2944@matrix.chaos.earth.li>
Message-ID: <4608B6D9.60707@serpentine.com>

Ian Lynagh wrote:

> So in answer to your actual question, personally I think cabal-rpm
> should be in its own package.

Fair enough.

	<b
From duncan.coutts at worc.ox.ac.uk  Tue Mar 27 07:11:34 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Mar 27 07:10:53 2007
Subject: [PATCH] Check the exit code from tar
In-Reply-To: <46085AC2.5020702@serpentine.com>
References: <46085AC2.5020702@serpentine.com>
Message-ID: <1174993894.4977.9.camel@localhost>

On Mon, 2007-03-26 at 16:44 -0700, Bryan O'Sullivan wrote:
> Prior to this change, if tar failed, the sdist command would fail to notice.

Applied. Thanks.

I added a simple tidy up while I was at it, to use rawSystemPath rather
than system. It gives us verbosity output and better error messages when
the command isn't found. Using rawSystem is preferable to system too in
most cases due to things like escaping.

Duncan

From stefanor at cox.net  Fri Mar 30 23:41:47 2007
From: stefanor at cox.net (Stefan O'Rear)
Date: Fri Mar 30 23:40:53 2007
Subject: Let's play Name That Extension!
Message-ID: <20070331034147.GA3910@localhost.localdomain>

A large number of the newer GHC extensions have no cabal name.  This
is a very bad situation because if Hugs/yhc/etc were to gain support
for (say) GADTs, it would not be possible to run cabal programs that
require them, since the way programs specify dependency is with
-fglasgow-exts.  Also, what is the protocol for requesting cabal
extension names?  I've many Cool Extension Ideas for my haskeell impl
project (nowhere near done). 

Stefan
From duncan.coutts at worc.ox.ac.uk  Sat Mar 31 02:10:27 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Mar 31 02:09:35 2007
Subject: Let's play Name That Extension!
In-Reply-To: <20070331034147.GA3910@localhost.localdomain>
References: <20070331034147.GA3910@localhost.localdomain>
Message-ID: <1175321428.4994.47.camel@localhost>

On Fri, 2007-03-30 at 20:41 -0700, Stefan O'Rear wrote:
> A large number of the newer GHC extensions have no cabal name.  This
> is a very bad situation because if Hugs/yhc/etc were to gain support
> for (say) GADTs, it would not be possible to run cabal programs that
> require them, since the way programs specify dependency is with
> -fglasgow-exts.  Also, what is the protocol for requesting cabal
> extension names?

You could do worse than to make up a sensible name and darcs send in
your patch to the Language.Haskell.Extension module to this list.

Duncan

From stefanor at cox.net  Sat Mar 31 02:15:49 2007
From: stefanor at cox.net (Stefan O'Rear)
Date: Sat Mar 31 02:14:54 2007
Subject: Let's play Name That Extension!
In-Reply-To: <1175321428.4994.47.camel@localhost>
References: <20070331034147.GA3910@localhost.localdomain>
	<1175321428.4994.47.camel@localhost>
Message-ID: <20070331061549.GA4192@localhost.localdomain>

On Sat, Mar 31, 2007 at 04:10:27PM +1000, Duncan Coutts wrote:
> On Fri, 2007-03-30 at 20:41 -0700, Stefan O'Rear wrote:
> > A large number of the newer GHC extensions have no cabal name.  This
> > is a very bad situation because if Hugs/yhc/etc were to gain support
> > for (say) GADTs, it would not be possible to run cabal programs that
> > require them, since the way programs specify dependency is with
> > -fglasgow-exts.  Also, what is the protocol for requesting cabal
> > extension names?
> 
> You could do worse than to make up a sensible name and darcs send in
> your patch to the Language.Haskell.Extension module to this list.
> 
> Duncan

I'll take that as permission :)

Stefan
From stefanor at cox.net  Sat Mar 31 02:20:34 2007
From: stefanor at cox.net (Stefan O'Rear)
Date: Sat Mar 31 02:19:39 2007
Subject: Let's play Name That Extension!
In-Reply-To: <20070331034147.GA3910@localhost.localdomain>
References: <20070331034147.GA3910@localhost.localdomain>
Message-ID: <20070331062034.GA4212@localhost.localdomain>

On Fri, Mar 30, 2007 at 08:41:47PM -0700, Stefan O'Rear wrote:
> A large number of the newer GHC extensions have no cabal name.  This
> is a very bad situation because if Hugs/yhc/etc were to gain support
> for (say) GADTs, it would not be possible to run cabal programs that
> require them, since the way programs specify dependency is with
> -fglasgow-exts.  Also, what is the protocol for requesting cabal
> extension names?  I've many Cool Extension Ideas for my haskeell impl
> project (nowhere near done). 

Forgot to mention...

Some of the existing extensions are not self explanatory.  How
flexible are FlexibleInstances and FlexibleContexts?  Does Rank2Types
involve the old GHC restrictions? (no pattern bindings, no partial
application, etc) Does RankNTypes include impredicativity?  Are
ScopedTypeVariables 6.4 style, 6.6 style, (ML style)?  What is a
ContextStack?  What are Generics?  And the last two made no sense
before I read the Hugs User Guide last(?) week.  The others are fine
however. 

Stefan
From duncan.coutts at worc.ox.ac.uk  Sat Mar 31 02:53:51 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Mar 31 02:52:58 2007
Subject: Let's play Name That Extension!
In-Reply-To: <20070331061549.GA4192@localhost.localdomain>
References: <20070331034147.GA3910@localhost.localdomain>
	<1175321428.4994.47.camel@localhost>
	<20070331061549.GA4192@localhost.localdomain>
Message-ID: <1175324031.4994.53.camel@localhost>

On Fri, 2007-03-30 at 23:15 -0700, Stefan O'Rear wrote:

> > You could do worse than to make up a sensible name and darcs send in
> > your patch to the Language.Haskell.Extension module to this list.
> 
> I'll take that as permission :)

Hah hah. I didn't say we'd apply the patches ;-)

But if you send patches then at least it gets people's attention and if
people don't like it they'll object and perhaps come up with something
better.

Duncan