From vivian.mcphail at paradise.net.nz  Tue Apr  3 11:33:49 2007
From: vivian.mcphail at paradise.net.nz (Vivian McPhail)
Date: Tue Apr  3 11:34:48 2007
Subject: darcs patch: added cppOptions and c2hsOptions
Message-ID: <003301c77605$7a53ba10$6601a8c0@box>

  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 23759 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070404/c2a12011/winmail-0001.bin
From a.d.clark at ed.ac.uk  Fri Apr  6 09:00:59 2007
From: a.d.clark at ed.ac.uk (allan)
Date: Fri Apr  6 07:33:30 2007
Subject: Building individual programs
Message-ID: <4616448B.2030609@ed.ac.uk>

Dear all

I have a cabal package which defines in the cabal package several 
programs to be built such as:

Executable:      prog1
Main-is:         examples/Prog1.hs
Ghc-options:     -Wall

Executable:      prog2
Main-is:         examples/Prog2.hs
Ghc-options:     -Wall

It's actually a library and the individual programs are a bunch of 
examples. When I work on one of these individually it's mildly annoying that
runhaskell Setup.hs build

builds all of them. I'd quite like to be able to do something like:
runhaskell Setup.hs build prog1
or even just
runhaskell Setup.hs prog1

to build only the first example.

I know about the "Buildable" field in the cabal file, but I was kind of 
hoping there was a way to do this such that the cabal file doesn't need 
to be continually modified (and runhaskell Setup.hs configure --..... 
re-run).

So is there a (standard) way to do this?
If not, I suppose the best way to do it would be in the Setup.hs file, 
ie could do something like:

processArgs :: [ String ] -> IO ()
processArgs [ "prog1" ]  = <Something to build prog1 with all the 
configuration information>  
processArgs _           = defaultMainWithHooks myHooks

if this is the best way, what should I have in the <Something .. > bit?

regards
allan


From haskell.vivian.mcphail at gmail.com  Sat Apr  7 06:48:23 2007
From: haskell.vivian.mcphail at gmail.com (Alexander McPhail)
Date: Sat Apr  7 06:47:03 2007
Subject: Building Projects under mingw that use c2hs
Message-ID: <7b03b3c60704070348i6a03040co2498764e03c2fd66@mail.gmail.com>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: mingw-c2hs-cabal-test.zip
Type: application/zip
Size: 9471 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070407/812af241/mingw-c2hs-cabal-test.zip
From haskell.vivian.mcphail at gmail.com  Sat Apr  7 09:45:20 2007
From: haskell.vivian.mcphail at gmail.com (Alexander McPhail)
Date: Sat Apr  7 09:43:59 2007
Subject: Building Projects under mingw that use c2hs [apologies for repost;
	archive seemed to scrub text portion, see archive for attached file]
Message-ID: <7b03b3c60704070645m6406a5f9ief36d74d610f994@mail.gmail.com>

Hi,

I have been trying to build a Cabal package that uses c2hs under mingw and
have run into some problems.

1) c2hs needed its own options because it has to pass a flag to its
invocation of the CPP.  I have already submitted this patch.  (I also
noticed a request for cppOptions in the Cabal.cabal file, so I added that)

2) When c2hs generates the
          foreign import ccall unsafe "path/to/include.h function" :: Type
    it doesn't insert the appropriate number of path separators for windows
( i.e. \\ not \)
    I have this patch sitting in my copy of c2hs.  But what I did is really
ugly:
    at around line 567 (process :: FilePath -> FilePath -> CST s ())
    I inserted:
    >    outFName' <- getSwitch outputSB
    >    -- on windows the path separator needs to be "\\" not "\"
    >    let outFName = replaceFileSeparator outFName'

    where replaceFileSeparator is defined as:
    >    replaceFileSeparator :: String -> String
    >    replaceFileSeparator []      = []
    >    replaceFileSeparator (x:xs)
    >       | x == '\\'           = "\\\\" ++ (replaceFileSeparator xs)
    >       | otherwise           = x : (replaceFileSeparator xs)

    this fixes the problem but stinks.

3) when compiling my c2hs generated .hs file, the c2hs generated .h file is
not being found.

$ ./Setup.lhs -v build
Reading parameters from
D:\Apps\MSYS\1.0\local\src\mingw-c2hs-cabal-test\cabal-root\mingw-
c2hs-cabal-test.buildinfo
Preprocessing library Mingw-c2hs-cabal-test-0.0.1...
D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C
-I..\include --cppopts=-I../include --include=src -o src\Cabal\MingwTest.hs
src\Cabal\MingwTest.chs
D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C
-I..\include --cppopts=-I../include --include=src -o src\Cabal\MingwTest2.hs
src\Cabal\MingwTest2.chs
Building Mingw-c2hs-cabal-test-0.0.1...
d:\Apps\ghc\ghc- 6.6\bin\ghc.exe -package-name
Mingw-c2hs-cabal-test-0.0.1--make -hide-all-packages -i
-idist\build\autogen -i. -isrc -I..\include
-#include "test.h" -odir dist\build -hidir dist\build -package base-2.0 -O
-package haskell98 -fglasgow-exts -fffi Cabal.MingwTest Cabal.MingwTest2C2HS
[1 of 3] Compiling C2HS             ( src/C2HS.hs, dist\build/C2HS.o )
[2 of 3] Compiling Cabal.MingwTest  ( src/Cabal/MingwTest.hs,
dist\build/Cabal/MingwTest.o )
C:\DOCUME~1\vivian\LOCALS~1\Temp\ghc31772_0\ghc31772_0.hc:6:33:
src\Cabal\MingwTest.h: No such file or directory

I have attached a set of files that will generate the errors I have
mentioned on mingw.

Cheers,

Vivian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070408/3e6a15e8/attachment-0001.htm
From ndmitchell at gmail.com  Tue Apr 10 10:24:55 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Tue Apr 10 10:23:24 2007
Subject: Setup sdist broken on Windows
Message-ID: <404396ef0704100724n7e67f71dt3abb593fa6a004ee@mail.gmail.com>

Hi,

On Windows, taking the filepath library:

Building source dist for filepath-1.0...
copy System\FilePath.hs to dist\src\filepath-1.0\.\System\FilePath.hs
copy System\FilePath\Posix.hs to dist\src\filepath-1.0\.\System\FilePath\Posix.h
s
copy System\FilePath\Windows.hs to dist\src\filepath-1.0\.\System\FilePath\Windo
ws.hs
copy System\FilePath\Internal.hs to dist\src\filepath-1.0\System\FilePath\Intern
al.hs
copy Setup.hs to dist\src\filepath-1.0\Setup.hs
copy filepath.cabal to dist\src\filepath-1.0\filepath.cabal
D:\bin\tar.exe -C dist\src -czf dist\filepath-1.0.tar.gz filepath-1.0
D:\bin\tar.exe: Cannot use compressed or remote archives
D:\bin\tar.exe: Error is not recoverable: exiting now
Setup: source tarball creation failed!  Tar exited with status 2

Using Cabal from about 2 minutes ago.

Any idea what is wrong?

Thanks

Neil
From duncan.coutts at worc.ox.ac.uk  Tue Apr 10 19:26:26 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Apr 10 19:25:02 2007
Subject: Setup sdist broken on Windows
In-Reply-To: <404396ef0704100724n7e67f71dt3abb593fa6a004ee@mail.gmail.com>
References: <404396ef0704100724n7e67f71dt3abb593fa6a004ee@mail.gmail.com>
Message-ID: <1176247586.5005.74.camel@localhost>

On Tue, 2007-04-10 at 15:24 +0100, Neil Mitchell wrote:
> Hi,
> 
> On Windows, taking the filepath library:


> D:\bin\tar.exe -C dist\src -czf dist\filepath-1.0.tar.gz filepath-1.0
> D:\bin\tar.exe: Cannot use compressed or remote archives
> D:\bin\tar.exe: Error is not recoverable: exiting now

> Any idea what is wrong?

Perhaps your tar doesn't like the -z option to create gziped tarballs,
or perhaps it relies on an external gzip command which is missing.

Obviously this whole calling tar+gzip solution is not so good on
windows. Bjorn has some code for reading and writing tar files but for
gzip we only have pure Haskell implementation of the decompression code,
for compression we'd need either my zlib binding (which uses an external
zlib.dll on windows, though in theory it could be statically linked) or
some other implementation.

Duncan

From simonmarhaskell at gmail.com  Thu Apr 12 04:41:29 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Thu Apr 12 04:39:56 2007
Subject: HEADS UP: Windows Vista users
Message-ID: <461DF0B9.4040200@gmail.com>

I've discovered a gotcha that happens when trying to use Cabal on Windows Vista. 
  If you compile Setup.lhs to a binary (as I often do), with something like 'ghc 
--make Setup', and then try to run it, you'll get something like this:

   $ ./Setup configure
   Setup.exe: Permission denied

This is due to a highly dubious security "feature" in Vista whereby it detects 
that you might be trying to run an installer-type program and refuses to execute 
the binary without elevated permissions.  The idea is that ordinary users won't 
be confused when their installer fails partway through due to insufficient 
permissions.  Unfortunately this works by matching on the name of the 
binary(!!!!), so names like "setup", "install" etc. are affected (there isn't a 
complete list, apparently).

Other casualties are:

  * cabal-setup (compiles Setup.hs to setup.exe)
  * The GHC build system, which now uses Cabal
  * 'make install', which runs /usr/bin/install.exe

More details in this MSDN thread:

   http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1021146&SiteID=1

and this Cygwin thread:

   http://www.cygwin.com/ml/cygwin/2006-12/msg00518.html

Fortunately you can turn off the behaviour: Start->Run->secpol.msc, then 
Security Settings -> Local Policies -> Security Options ! UAC: Detect 
application installations and prompt for elevation.  It appears you need to 
reboot for the change to take effect.

The right workaround is to add a manifest to the binary asking for no security 
elevation, apparently this is quite easy.  We'll need to get GHC to do this for 
every binary it generates in the future.

For now, I'll put a note in the building guide and FAQ, and make a ticket for 
GHC 6.6.2 to do the manifest thing.

Cheers,
	Simon
From bos at serpentine.com  Sun Apr 15 02:07:10 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Sun Apr 15 02:05:51 2007
Subject: Problems with "make" after "Setup makefile"
Message-ID: <4621C10E.9060008@serpentine.com>

Hi, Simon -

I've had a chance to try out your makefile patch for Cabal tonight as 
part of pulling out cabal-rpm into a standalone program, and I'm finding 
  problems with it.

The first is with the code that attempts to use "mkdir" to create the 
hierarchy of object directories.  It will in several instances try to 
generate a directory without first having created its parent.  You can 
reproduce this by trying to build Cabal in this way; it will fail 
because it's trying to mkdir Language/Haskell, but does not first create 
Language.  I've hacked around this locally by invoking "mkdir -p" 
instead, but that's not portable to old systems.

The second problem occurs immediately afterwards.  If you try to build 
e.g. the binary package, it will fail almost immediately, as follows:

binary-0.3 $ make
Panic! dist/build/Data/Binary/Get.o exists, but 
dist/build/Data/Binary/Get.hi does not.

This error message is misleading.  The dependency that make is trying to 
follow is this:

dist/build/Data/Binary/Get.hi: dist/build/Data/Binary/Get.o

That triggers this portion of the Makefile:

%.$(way_)hi : %.$(way_)o
         @if [ ! -f $@ ] ; then \
             echo Panic! $< exists, but $@ does not.; \
             exit 1; \
         else exit 0 ; \
         fi

In this case, neither side of the rule exists.  I'm not too sure what 
this is trying to do, or whether there's a step I ought to be taking 
between "Setup makefile" and "make", but alas, no luck so far.

Thanks for any light you can shed.

	<b
From bos at serpentine.com  Sun Apr 15 02:20:10 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Sun Apr 15 02:18:58 2007
Subject: [PATCH] Split SrcDist::sdist into several functions
Message-ID: <4621C41A.40206@serpentine.com>

This patch merely refactors the sdist function in the SrcDist module so 
that its phases (prepare a tree, build an archive) are available 
individually as functions to outside callers.

This change makes life easier for cabal-rpm.

Please apply.

darcs pull http://darcs.serpentine.com/cabal-for-upstream

Thanks,

	<b
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdist-split.patch
Type: text/x-patch
Size: 22568 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070414/f42ce1f5/sdist-split-0001.bin
From bos at serpentine.com  Sun Apr 15 02:27:39 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Sun Apr 15 02:26:18 2007
Subject: [ANNOUNCE] cabal-rpm: build RPM packages from Cabal packages
Message-ID: <4621C5DB.3010305@serpentine.com>

As has happened with cabal-install et al, and in response to feedback 
when I posted my original "Setup rpm" patches, I've rewritten that patch 
as a standalone program, called "cabal-rpm".  Unlike other tools that do 
this job, cabal-rpm is written in Haskell, and it uses the Cabal APIs 
directly.

Simply run cabal-rpm in the top-level directory of a Cabalised project 
and it will build a binary RPM for you.  No muss, no fuss.

I'm thinking about going a step further with this and integrating some 
of the functionality of cabal-install, such that cabal-rpm could 
download and build RPMs of multiple packages and missing dependencies. 
Would this be interesting to the cabal-install folks?  If so, would you 
be willing to take patches to librarify some of cabal-install's internals?

It shouldn't be hard to generate packaging data for non-RPM-based 
distros, too, such as Debian and Ubuntu.  I'll probably look into that 
when time permits.

Regards,

	<b
From bos at serpentine.com  Sun Apr 15 02:28:35 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Sun Apr 15 02:27:15 2007
Subject: [ANNOUNCE] cabal-rpm: build RPM packages from Cabal packages
In-Reply-To: <4621C5DB.3010305@serpentine.com>
References: <4621C5DB.3010305@serpentine.com>
Message-ID: <4621C613.9030505@serpentine.com>

Bryan O'Sullivan wrote:
> As has happened with cabal-install et al, and in response to feedback 
> when I posted my original "Setup rpm" patches, I've rewritten that patch 
> as a standalone program, called "cabal-rpm".

And in all my blathering, I forgot to include a link.

darcs get http://darcs.serpentine.com/cabal-rpm

	<b
From simonmarhaskell at gmail.com  Mon Apr 16 10:03:29 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Mon Apr 16 10:01:42 2007
Subject: Problems with "make" after "Setup makefile"
In-Reply-To: <4621C10E.9060008@serpentine.com>
References: <4621C10E.9060008@serpentine.com>
Message-ID: <46238231.7000008@gmail.com>

Bryan O'Sullivan wrote:

> I've had a chance to try out your makefile patch for Cabal tonight as 
> part of pulling out cabal-rpm into a standalone program, and I'm finding 
>  problems with it.
> 
> The first is with the code that attempts to use "mkdir" to create the 
> hierarchy of object directories.  It will in several instances try to 
> generate a directory without first having created its parent.  You can 
> reproduce this by trying to build Cabal in this way; it will fail 
> because it's trying to mkdir Language/Haskell, but does not first create 
> Language.  I've hacked around this locally by invoking "mkdir -p" 
> instead, but that's not portable to old systems.
> 
> The second problem occurs immediately afterwards.  If you try to build 
> e.g. the binary package, it will fail almost immediately, as follows:
> 
> binary-0.3 $ make
> Panic! dist/build/Data/Binary/Get.o exists, but 
> dist/build/Data/Binary/Get.hi does not.

Thanks, I've fixed both of these now, and checked that Cabal and binary both 
build with setup makefile.

Cheers,
	Simon
From igloo at earth.li  Tue Apr 17 19:13:57 2007
From: igloo at earth.li (Ian Lynagh)
Date: Tue Apr 17 19:12:03 2007
Subject: darcs patch: Stop pretending we might not have any Us... (and 3
	more)
Message-ID: <E1Hdws1-0007uo-8N@matrix.matrix.chaos.earth.li>


Hi Duncan,

Patches for consideration.

The first you have agreed to in the past, but I can't remember if you
said it should go into the packages/Cabal repo or a repo for a release
even further in the future.


Thanks
Ian


Tue Apr 17 23:42:20 BST 2007  Ian Lynagh <igloo@earth.li>
  * Stop pretending we might not have any UserHooks

Tue Apr 17 23:50:31 BST 2007  Ian Lynagh <igloo@earth.li>
  * Small tidyup

Tue Apr 17 23:56:57 BST 2007  Ian Lynagh <igloo@earth.li>
  * Stop having hooks return an ExitCode that we then ignore

Wed Apr 18 00:03:11 BST 2007  Ian Lynagh <igloo@earth.li>
  * Behave the same on Windows and non-Windows

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 31194 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070418/db259e5e/attachment-0001.bin
From duncan.coutts at worc.ox.ac.uk  Tue Apr 17 23:31:08 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Apr 17 23:29:25 2007
Subject: darcs patch: added cppOptions and c2hsOptions
In-Reply-To: <003301c77605$7a53ba10$6601a8c0@box>
References: <003301c77605$7a53ba10$6601a8c0@box>
Message-ID: <1176867069.25192.10.camel@localhost>

On Wed, 2007-04-04 at 03:33 +1200, Vivian McPhail wrote:

> Wed Apr  4 03:32:49 New Zealand Standard Time 2007  Vivian McPhail
> <omconsult@gmail.com>
>   * added cppOptions and c2hsOptions

Hia Vivian,

Can you explain to me again exactly why we need these extra options? As
I see it, cpp options can just be included in the cc options, is there
any need to separate them?

Cabal currently looks for -D* -U* and -I* flags in the cc options and
passes them to c2hs. Are there any other ones that we are missing there?
It's quite convenient for users not to have to separate the cc flags
into cpp ones, since many other tools intermingle them (off the top of
my head I can think of pkg-config).

As for the c2hs options, again I'm not clear as to why this is
necessary. c2hs doesn't support that many interesting flags:

  -C CPPOPTS   --cppopts=CPPOPTS    pass CPPOPTS to the C preprocessor
  -c CPP       --cpp=CPP            use executable CPP to invoke C preprocessor
  -d TYPE      --dump=TYPE          dump internal information (for debugging)
  -h, -?       --help               brief help (the present message)
  -i INCLUDE   --include=INCLUDE    include paths for .chi files
  -k           --keep               keep pre-processed C header
  -l           --copy-library       copy `C2HS' library module in
  -o FILE      --output=FILE        output result to FILE (should end in .hs)
  -p PLATFORM  --platform=PLATFORM  platform to use for cross compilation
  -t PATH      --output-dir=PATH    place generated files in PATH
  -v           --version            show version information

I think all of these are either not useful or can be selected automatically.

As for the optional .h file that can be passed on the command line, the
better way to do that is to put the #include inside the .chs file.

The alternative is to extend c2hs to accept many .h files on the command
line and we can pass all the files in the 'includes:' field to c2hs. I'm
considering extending c2hs to allow this. I'm also planning to change
c2hs so that the .h file it generates will not clash with anything else,
for foo.chs it'll generate foo.chs.h and possibly foo.chs.c too.

Is there anything I've missed?

Duncan

From duncan.coutts at worc.ox.ac.uk  Tue Apr 17 23:50:07 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Apr 17 23:48:23 2007
Subject: darcs patch: Stop pretending we might not have any Us... (and
	3 more)
In-Reply-To: <E1Hdws1-0007uo-8N@matrix.matrix.chaos.earth.li>
References: <E1Hdws1-0007uo-8N@matrix.matrix.chaos.earth.li>
Message-ID: <1176868207.25192.13.camel@localhost>

On Wed, 2007-04-18 at 00:13 +0100, Ian Lynagh wrote:
> Hi Duncan,
> 
> Patches for consideration.
> 
> The first you have agreed to in the past, but I can't remember if you
> said it should go into the packages/Cabal repo or a repo for a release
> even further in the future.

I'm happy with it all. It does change the hooks interface again, but
we've already done that once since the last release so doing it again is
no worse. I fixed Cabal's own Setup.lhs file.

Duncan

From igloo at earth.li  Wed Apr 18 09:13:18 2007
From: igloo at earth.li (Ian Lynagh)
Date: Wed Apr 18 09:11:21 2007
Subject: building, rebuilding, problems, ALUT,..
In-Reply-To: <009301c780e1$0e960c60$78448351@cr3lt>
References: <009301c780e1$0e960c60$78448351@cr3lt>
Message-ID: <20070418131318.GA31540@matrix.chaos.earth.li>

On Tue, Apr 17, 2007 at 12:10:48PM +0100, Claus Reinke wrote:
> after a long while, i'm trying to update and rebuild my local ghc HEAD 
> (windows).
> as usual, there are problems:
> 
> 2. filepath has been added sometime after my last attempt

Good point - boot now checks that all the corelibs are here.

> 3. windows configure has acquired yet another extra option, it seems. why 
> can't
>    i just run ./configure and have it find the right things in the PATH, as 
>    on other
>    platforms? the only supported build is mingw, so it should look for 
>    mingw versions,
>    and issue a warning if cygwin versions are found instead (a warning 
>    because some
>    people do want cygwin builds).

A patch to simplify the Windows story would be great, but it's fairly
low priority for me as (a) it does actually work at the moment
(b) removing one or two configure flags doesn't really make much
difference; copy and pasting 3 or 4 is just as easy as 1 or 2, so you
really do have to solve all the issues to get a payoff.

> 4. make falls over in ALUT (i don't have OpenAL installed, so neither that 
> nor ALUT
>    should be built). last part of log appended below.

Right, I've been fixing up the various exciting new failure modes that
have popped up now that we use Cabal to build the libraries. However, I
think that trying to detect that this latest one is going to happen
before configure runs is one step too far.

There are 9 packages that depend on other extralibs:

ALUT (OpenGL, OpenAL)
GLUT (OpenGL)
HGL (X11) (should sometimes depend on Win32 instead?)
OpenAL (OpenGL)
cgi (network, parsec, mtl, xhtml)
fgl (mtl)
network (parsec)
regex-compat (regex-base, regex-posix)
regex-posix (regex-base)

but I think only the GL/AL family, HGL and X11 can decide that they are
unbuildable, so I think that only these can fail in this way:

ALUT (OpenGL, OpenAL)
GLUT (OpenGL)
HGL (X11) (should sometimes depend on Win32 instead?)
OpenAL (OpenGL)

I see 3 possible solutions:

1) If Cabal find the dependencies aren't satisfied then it puts
   "buildable: False" somewhere and exits successfully. I quite like
   this from a consistency point of view (it's what happens when
   ./configure decides that the package is unbuildable).

2) We remove ALUT, GLUT, HGL, OpenAL (and OpenGL too for consistency?)
   from extralibs. I think these are probably among the least use
   extralibs anyway.

3) We declare that if you put unbuildable extralibs in your GHC tree
   then the build might break.


My order of preference is:

    1) (done by someone else)
    2) (also removing OpenGL)
    2) (leaving OpenGL as an extralib)
    3)
    1) (done by me)

Anyone else got an opinion (or a Cabal patch?  :-)  )


Thanks
Ian

From bertram.felgenhauer at googlemail.com  Thu Apr 19 06:59:21 2007
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Thu Apr 19 06:57:28 2007
Subject: darcs patch: add extra-includes field to buildinfo
Message-ID: <1176980361.990@zombie>

Hi,

please consider the attached patch. It allows installing include files
into $(lib)/include without automatically including them in compilations
via C. Use cases can be found in the package description below. The
base package could take advantage of this feature immediately.

The patch is possibly incomplete: the field is completely ignored
when installing packages for Hugs, which is bad if the header files
are indeed used for Haskell code in a different package.

Bertram

Thu Apr 19 12:42:24 CEST 2007  Bertram Felgenhauer <int-e@gmx.de>
  * add extra-includes field to buildinfo
  The patch targets packages that come with an include file which includes
  other include files in turn, or packages that want to install header files
  that are used for preprocessing Haskell code rather than C code.
  This will allow the base package to install its header files properly.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 24128 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070419/75dc87e8/attachment-0001.bin
From vivian.mcphail at paradise.net.nz  Fri Apr 20 00:32:18 2007
From: vivian.mcphail at paradise.net.nz (Vivian McPhail)
Date: Fri Apr 20 00:31:55 2007
Subject: darcs patch: added cppOptions and c2hsOptions
Message-ID: <007b01c78304$e1869570$6601a8c0@box>

Hi Duncan,

I added cppOptions because in the Cabal.cabal file there was a comment to
add cppOptions and so I did it.

With respect to c2hsOptions, the problem is that c2hs passes options to the
CPP nonstandardly (with --cppopts=), so even if I have an -I* option in my
ccOptions that gets passed to c2hs, this works for c2hs, but doesn't get
passed to the cpp that c2hs uses.

I've sent a message to the c2hs/cabal mailing list with a dummy package that
recreates all the problems I had on mingw/WinXP.  The reason the c files are
outside the Cabal hierarchy is that they are supposed to mimic libs/headers
that are already on the system and would (normally) be found with an
autoconf script.

I think it would be a great idea to change the name of the .h file that c2hs
generates.  It would make naming Haskell sources/modules more consistent
with their targets.

Cheers,

Vivian 

> -----Original Message-----
> From: Duncan Coutts [mailto:duncan.coutts@worc.ox.ac.uk]
> Sent: Wednesday, 18 April 2007 3:31 p.m.
> To: Vivian McPhail
> Cc: cabal-devel@haskell.org
> Subject: Re: darcs patch: added cppOptions and c2hsOptions
> 
> On Wed, 2007-04-04 at 03:33 +1200, Vivian McPhail wrote:
> 
> > Wed Apr  4 03:32:49 New Zealand Standard Time 2007  Vivian McPhail 
> > <omconsult@gmail.com>
> >   * added cppOptions and c2hsOptions
> 
> Hia Vivian,
> 
> Can you explain to me again exactly why we need these extra options? 
> As I see it, cpp options can just be included in the cc options, is 
> there any need to separate them?
> 
> Cabal currently looks for -D* -U* and -I* flags in the cc options and 
> passes them to c2hs. Are there any other ones that we are missing 
> there?
> It's quite convenient for users not to have to separate the cc flags 
> into cpp ones, since many other tools intermingle them (off the top of 
> my head I can think of pkg-config).
> 
> As for the c2hs options, again I'm not clear as to why this is 
> necessary. c2hs doesn't support that many interesting flags:
> 
>   -C CPPOPTS   --cppopts=CPPOPTS    pass CPPOPTS to the C preprocessor
>   -c CPP       --cpp=CPP            use executable CPP to 
> invoke C preprocessor
>   -d TYPE      --dump=TYPE          dump internal information 
> (for debugging)
>   -h, -?       --help               brief help (the present message)
>   -i INCLUDE   --include=INCLUDE    include paths for .chi files
>   -k           --keep               keep pre-processed C header
>   -l           --copy-library       copy `C2HS' library module in
>   -o FILE      --output=FILE        output result to FILE 
> (should end in .hs)
>   -p PLATFORM  --platform=PLATFORM  platform to use for cross 
> compilation
>   -t PATH      --output-dir=PATH    place generated files in PATH
>   -v           --version            show version information
> 
> I think all of these are either not useful or can be selected 
> automatically.
> 
> As for the optional .h file that can be passed on the command line, 
> the better way to do that is to put the #include inside the .chs file.
> 
> The alternative is to extend c2hs to accept many .h files on the 
> command line and we can pass all the files in the 'includes:' field to 
> c2hs. I'm considering extending c2hs to allow this. I'm also planning 
> to change c2hs so that the .h file it generates will not clash with 
> anything else, for foo.chs it'll generate foo.chs.h and possibly 
> foo.chs.c too.
> 
> Is there anything I've missed?
> 
> Duncan
> 

From duncan.coutts at worc.ox.ac.uk  Fri Apr 20 02:10:08 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Fri Apr 20 02:08:09 2007
Subject: darcs patch: added cppOptions and c2hsOptions
In-Reply-To: <007b01c78304$e1869570$6601a8c0@box>
References: <007b01c78304$e1869570$6601a8c0@box>
Message-ID: <1177049408.25192.214.camel@localhost>

On Fri, 2007-04-20 at 16:32 +1200, Vivian McPhail wrote:
> Hi Duncan,
> 
> I added cppOptions because in the Cabal.cabal file there was a comment to
> add cppOptions and so I did it.

Ok.

> With respect to c2hsOptions, the problem is that c2hs passes options to the
> CPP nonstandardly (with --cppopts=), so even if I have an -I* option in my
> ccOptions that gets passed to c2hs, this works for c2hs, but doesn't get
> passed to the cpp that c2hs uses.

Sorry, I still don't see it fully. Could you say exactly what the c2hs
command line is that you use when it works and what command line cabal
uses that does not work (and that your patch solves).

> I've sent a message to the c2hs/cabal mailing list with a dummy package that
> recreates all the problems I had on mingw/WinXP.

I'm not sure that we got this. Could you send it again, perhaps ccing it
to me directly.

Duncan

From vivian.mcphail at paradise.net.nz  Fri Apr 20 02:38:49 2007
From: vivian.mcphail at paradise.net.nz (Vivian McPhail)
Date: Fri Apr 20 02:38:25 2007
Subject: darcs patch: added cppOptions and c2hsOptions
In-Reply-To: <1177049408.25192.214.camel@localhost>
References: <007b01c78304$e1869570$6601a8c0@box>
	<1177049408.25192.214.camel@localhost>
Message-ID: <008101c78316$8ede7010$6601a8c0@box>

Hi:

Here is what Cabal does:

$ ./Setup.lhs -v build
C:\DOCUME~1\vivian\LOCALS~1\Temp\ghc139100_0\ghc139100_0.hc:8:37:
../src/Matlab/C/CMatrix.h: No such file or directory
Reading parameters from
D:\Apps\MSYS\1.0\local\src\MatlabCompiling\matlab.buildinfo
Preprocessing library Matlab-0.0.1...
D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C
-Ic:\Apps\MATLAB704\bin\win32\..\..\extern\include -o
src\Matlab\C\CMatrix.hs src\Matlab\C\CMatrix.chs
D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C
-Ic:\Apps\MATLAB704\bin\win32\..\..\extern\include -o src\Matlab\C\CMat.hs
src\Matlab\C\CMat.chs
c2hs.exe: Matlab/C/CMatrix.chi not found in:
.

Setup.lhs: got error code while preprocessing: Matlab.C.CMat

Here is my command that works (from MatlabCompiling/test)

$ c2hs --cppopts=-I/c/Apps/MATLAB704/extern/include --include=../src
../src/Matlab/C/CMatrix.chs

Here is the addition to matlab.buildinfo which makes Cabal work:

c2hs-options: --cppopts=-I/c/Apps/MATLAB704/bin/win32/../../extern/include
--include=src

I'm also attaching a file which should recreate all the errors that I've
found on MinGW/WinXP.  Note that there are files outside the cabal hierarchy
to simulate headers/library which are already on the system and outside the
packager's control.

Cheers,

Vivian 

> -----Original Message-----
> From: Duncan Coutts [mailto:duncan.coutts@worc.ox.ac.uk] 
> Sent: Friday, 20 April 2007 6:10 p.m.
> To: Vivian McPhail
> Cc: cabal-devel@haskell.org
> Subject: RE: darcs patch: added cppOptions and c2hsOptions
> 
> On Fri, 2007-04-20 at 16:32 +1200, Vivian McPhail wrote:
> > Hi Duncan,
> > 
> > I added cppOptions because in the Cabal.cabal file there 
> was a comment 
> > to add cppOptions and so I did it.
> 
> Ok.
> 
> > With respect to c2hsOptions, the problem is that c2hs 
> passes options 
> > to the CPP nonstandardly (with --cppopts=), so even if I 
> have an -I* 
> > option in my ccOptions that gets passed to c2hs, this works 
> for c2hs, 
> > but doesn't get passed to the cpp that c2hs uses.
> 
> Sorry, I still don't see it fully. Could you say exactly what 
> the c2hs command line is that you use when it works and what 
> command line cabal uses that does not work (and that your 
> patch solves).
> 
> > I've sent a message to the c2hs/cabal mailing list with a dummy 
> > package that recreates all the problems I had on mingw/WinXP.
> 
> I'm not sure that we got this. Could you send it again, 
> perhaps ccing it to me directly.
> 
> Duncan
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mingw-c2hs-cabal-test.zip
Type: application/x-zip-compressed
Size: 9471 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070420/1415308a/mingw-c2hs-cabal-test.bin
From duncan.coutts at worc.ox.ac.uk  Fri Apr 20 06:17:21 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Fri Apr 20 06:15:24 2007
Subject: darcs patch: added cppOptions and c2hsOptions
In-Reply-To: <008101c78316$8ede7010$6601a8c0@box>
References: <007b01c78304$e1869570$6601a8c0@box>
	<1177049408.25192.214.camel@localhost>
	<008101c78316$8ede7010$6601a8c0@box>
Message-ID: <1177064241.25192.227.camel@localhost>

Hia Vivian,

Ok, I think the right thing to do here is to change cabal and c2hs
slightly, but not to add any new fields. I think we can make it all do
the right thing without having to manually pass extra args to c2hs.

The first thing to do is to have cabal tell c2hs where to look for all
the .chi files. This depends on where we tell c2hs to put them. I think
the right place for the generated .h, .hs and .chi files is in the
dist/build directory. Then we tell ghc to look there when compiling.

I'm looking into it.

Duncan

On Fri, 2007-04-20 at 18:38 +1200, Vivian McPhail wrote:
> Here is what Cabal does:
> 
> $ ./Setup.lhs -v build
> C:\DOCUME~1\vivian\LOCALS~1\Temp\ghc139100_0\ghc139100_0.hc:8:37:
> ../src/Matlab/C/CMatrix.h: No such file or directory
> Reading parameters from
> D:\Apps\MSYS\1.0\local\src\MatlabCompiling\matlab.buildinfo
> Preprocessing library Matlab-0.0.1...
> D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C
> -Ic:\Apps\MATLAB704\bin\win32\..\..\extern\include -o
> src\Matlab\C\CMatrix.hs src\Matlab\C\CMatrix.chs
> D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C
> -Ic:\Apps\MATLAB704\bin\win32\..\..\extern\include -o src\Matlab\C\CMat.hs
> src\Matlab\C\CMat.chs
> c2hs.exe: Matlab/C/CMatrix.chi not found in:
> .


> Here is my command that works (from MatlabCompiling/test)
> 
> $ c2hs --cppopts=-I/c/Apps/MATLAB704/extern/include --include=../src
> ../src/Matlab/C/CMatrix.chs
> 
> Here is the addition to matlab.buildinfo which makes Cabal work:
> 
> c2hs-options: --cppopts=-I/c/Apps/MATLAB704/bin/win32/../../extern/include
> --include=src



From bertram.felgenhauer at googlemail.com  Fri Apr 20 09:28:56 2007
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Fri Apr 20 09:26:56 2007
Subject: darcs patch: don't automatically include install-incl... (and 2
	more)
Message-ID: <1177075736.16206@zombie>

Hi,

I've discussed my previous patch ("add extra-includes field to buildinfo")
with Duncan and we came to the conclusion that adding a new field is not
necessary.

Instead, the semantics of the install-include: field can be changed so
that the files listed there are only installed but not automatically
included in compilations via C. The inclusion can still be achieved by
listing the file in the includes: field as well. (This is an incompatible
change but it should not affect too many packages, I hope.)

See the patch descriptions below for details. The patches are tested
with ghc HEAD with an updated cabal file for the base file.

Thinking about these patches uncovered a different problem: it is hard
to include files that come with the package itself in the packages'
compilation. The base package (my working example) uses the trick of
listing "../../includes" in the include-dirs field. This works, but
it's not very pretty. I have no good solution for that problem at the
moment though.

Bertram

Fri Apr 20 14:34:18 CEST 2007  Bertram Felgenhauer <int-e@gmx.de>
  * don't automatically include install-include: headers into compilations via C
  This way it's possible to install header files that are meant for preprocessing
  Haskell code, or header files that are meant to be indirectly included by
  others.

Fri Apr 20 14:35:27 CEST 2007  Bertram Felgenhauer <int-e@gmx.de>
  * install headers for all compilers
  This patch moves the installation of header files from Distribution.Simple.GHC
  to Distribution.Simple.Install. This is required for the header files to be
  usable for preprocessing Haskell code in other packages.

Fri Apr 20 15:15:24 CEST 2007  Bertram Felgenhauer <int-e@gmx.de>
  * update documentation for install-headers: field

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 26647 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070420/7eb790fa/attachment-0001.bin
From duncan.coutts at worc.ox.ac.uk  Sat Apr 21 01:39:26 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Apr 21 01:37:28 2007
Subject: darcs patch: don't automatically include install-incl... (and
	2 more)
In-Reply-To: <1177075736.16206@zombie>
References: <1177075736.16206@zombie>
Message-ID: <1177133966.25192.230.camel@localhost>

On Fri, 2007-04-20 at 15:28 +0200, Bertram Felgenhauer wrote:
> Hi,
> 
> I've discussed my previous patch ("add extra-includes field to buildinfo")
> with Duncan and we came to the conclusion that adding a new field is not
> necessary.

Cheers Bertram,

I'll give people a day or two to raise issues about this, otherwise I'm
inclined to apply it.

Duncan

From duncan.coutts at worc.ox.ac.uk  Sat Apr 21 08:32:08 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Apr 21 08:30:09 2007
Subject: darcs patch: added cppOptions and c2hsOptions
In-Reply-To: <1177064241.25192.227.camel@localhost>
References: <007b01c78304$e1869570$6601a8c0@box>
	<1177049408.25192.214.camel@localhost>
	<008101c78316$8ede7010$6601a8c0@box>
	<1177064241.25192.227.camel@localhost>
Message-ID: <1177158728.7696.13.camel@localhost>

On Fri, 2007-04-20 at 20:17 +1000, Duncan Coutts wrote:
> Hia Vivian,
[...]
> I'm looking into it.

I have a patch, I'll send it soonish (probably Monday) for other people
to review and test.

It's a general change to the way Cabal does pre-processing. Instead of
generating the .hs files in place in the source tree we put them all in
a special build tree in the dist dir (like where we put the .o and .hi
files, but not actually the same directory).

So the patch does that for all pre-processors, and in addition gives the
pre-processors a bit more information so that they can distinguish the
base name of the output file and the output dir prefix. This allows us
to tell c2hs this relative path so that it will use it when it generates
links to .h files in the .hs files it generates.

This also depends on a separate patch to c2hs.

Duncan

From ross at soi.city.ac.uk  Sat Apr 21 17:35:55 2007
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Sat Apr 21 17:33:53 2007
Subject: darcs patch: added cppOptions and c2hsOptions
In-Reply-To: <1177158728.7696.13.camel@localhost>
References: <007b01c78304$e1869570$6601a8c0@box>
	<1177049408.25192.214.camel@localhost>
	<008101c78316$8ede7010$6601a8c0@box>
	<1177064241.25192.227.camel@localhost>
	<1177158728.7696.13.camel@localhost>
Message-ID: <20070421213555.GA3000@soi.city.ac.uk>

On Sat, Apr 21, 2007 at 10:32:08PM +1000, Duncan Coutts wrote:
> I have a patch, I'll send it soonish (probably Monday) for other people
> to review and test.
> 
> It's a general change to the way Cabal does pre-processing. Instead of
> generating the .hs files in place in the source tree we put them all in
> a special build tree in the dist dir (like where we put the .o and .hi
> files, but not actually the same directory).

I've been meaning to do something like that, to get the generated files
under dist, and to separate out the compiler-independent part of the code.
There should be no need for the compiler-specific parts to worry about
main-is or hs-source-dirs, when the first phase can handle those.

Another benefit is that we could include compiler-independent preprocessor
output (where possible) in source distributions.  If the package is
built in an environment lacking that preprocessor, it can use the
shipped output.  If the preprocessor is available, it can run it with
compiler-specific flags (e.g. happy -agc).  Not all preprocessors can
produce compiler-independent output, though.

From duncan.coutts at worc.ox.ac.uk  Sun Apr 22 03:31:31 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Apr 22 03:29:34 2007
Subject: cabal ignores ld-options?
In-Reply-To: <20070421231118.GA4927@a5.repetae.net>
References: <20070421231118.GA4927@a5.repetae.net>
Message-ID: <1177227091.7696.21.camel@localhost>

On Sun, 2007-04-22 at 00:11 +0100, Frederik Eaton wrote:
> Hello,
> 
> I am trying to get cabal to link an object file with a library.

Do you mean you want to link to an existing C library? You don't need
ld-options for that of course, just extra-libraries (and maybe
extra-lib-dirs).

> I tried naming it in an ld-options: line, but it didn't show up in the
> arguments to 'ld'. Is this the correct behaviour?

For a bug report like this it's much more helpful if you give more
detail on exactly what you did, exactly what happened and what you were
expecting. In this case for example you could include the output of
runghc Setup.hs build -v so you and we could see exactly how cabal is
calling ghc/ld/whatever.

The ld-options are passed to ghc when it links an executable and they
also get included in library package registration information.

Duncan

From duncan.coutts at worc.ox.ac.uk  Sun Apr 22 06:33:42 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Apr 22 06:31:44 2007
Subject: darcs patch: Put pre-processed source into the dist/b... (and 2
	more)
Message-ID: <1070422103350.20154@cse.unsw.edu.au>

Those patches I was talking about. I'd apreciate a review :-)

Actually to test it with c2hs also needs a patch to c2hs that I'll send
tomorrow. But it should work for alex & happy etc already.

Duncan

Sun Apr 22 19:56:31 EST 2007  Duncan Coutts <duncan.coutts@worc.ox.ac.uk>
  * Put pre-processed source into the dist/build dir rather than src dirs
  This is generally just a nicer thing to do, we should probably aim to
  not write any files into the source tree at all.
  The main change is in the preprocessModule function. It now takes an extra
  arg which is the destination directory. For now I'm passing the buildDir,
  but we could consider putting pre-processed files into a separate fir
  from where the .o and .hi files end up.
  To work out the correct destination file we need to know not only the source
  file but which of the search dirs it was found in, since the relative file
  name will be the name of the source file relative to the search dir it was
  found in, not the name relative to the top of the source tree. This is so that
  we will be able to find the pre-processed .hs file just by adding dist/build
  to the sources search path when we compile (eg with -i for ghc).
  This almost certainly breaks the sdist thing where pre-processed files get
  included into the tarball. So that'll need looking at.

Sun Apr 22 20:05:58 EST 2007  Duncan Coutts <duncan.coutts@worc.ox.ac.uk>
  * Generalise PreProcessors to take more detailed args
  Most pre-processors just need the full source file and target file names.
  More complicated ones where the generated files have to embed links to each
  other need more information. For example c2hs generates .hs file that
  reference generated .h files. These links should be relative to the dist/build
  dir and not to the top of the source tree, since we do not want to add -I. to
  the includes search path. We only want to use -Idist/build, hence the embeded
  links must be relative to that. Therefor c2hs needs to know the base output
  directory as well as the name of the file relative to that.
  So we add a new type PreProcessorFull that has this extra info and a function
  simplePP :: :: PreProcessor -> PreProcessorFull
  for the common case of most existing pre-processors that do not need this
  extra info.
  This patch doesn't actually change the c2hs stuff, that comes next.

Sun Apr 22 20:26:17 EST 2007  Duncan Coutts <duncan.coutts@worc.ox.ac.uk>
  * call c2hs using the more detailed info
  we use --output-dir=dist/base
  and --output=<file relative to the search dir it was found in>.hs
  This actually depends on a patch in c2hs to make it treat --output-dir
  in the way we want. That patch will be forthcomming soonish.
  But the point is:
  c2hs --output-dir=dist/base --output=Foo/Bar.hs src/Foo/Bar.chs
  will generate dist/base/Foo/Bar.hs and also dist/base/Foo/Bar.h
  but inside the .hs file it'll reference Foo/Bar.h so when we compile the
  .hs file we have to -Idist/base
  Clear as mud?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 31010 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070422/dbeed4da/attachment-0001.bin
From duncan.coutts at worc.ox.ac.uk  Sun Apr 22 23:37:14 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Apr 22 23:35:15 2007
Subject: cabal ignores ld-options?
In-Reply-To: <20070422105149.GC3323@a5.repetae.net>
References: <20070421231118.GA4927@a5.repetae.net>
	<1177227091.7696.21.camel@localhost>
	<20070422105149.GC3323@a5.repetae.net>
Message-ID: <1177299434.7696.63.camel@localhost>

On Sun, 2007-04-22 at 11:51 +0100, Frederik Eaton wrote:
> On Sun, Apr 22, 2007 at 05:31:31PM +1000, Duncan Coutts wrote:
> > On Sun, 2007-04-22 at 00:11 +0100, Frederik Eaton wrote:
> > > Hello,
> > > 
> > > I am trying to get cabal to link an object file with a library.

Frederik, in case it's not clear, the reason you're running into
problems is because you're doing things people haven't done much before
with cabal, that is try and use it as part of a larger multi-language
project. I'm not at all saying that's a bad thing, it's just that's why
you're noticing these missing features.

> > Do you mean you want to link to an existing C library? You don't need
> > ld-options for that of course, just extra-libraries (and maybe
> > extra-lib-dirs).
> 
> No, I have an object file which I have compiled with g++, and a
> Haskell library which uses symbols from it. I usually just put it on
> the ghc command line and that seems to work, but don't know what the
> Cabal equivalent of this technique is.

I see. It might be easier to make this into a library, ie an archive .a
file. Cabal has no particular mechanism for linking in arbitrary .o
files but it does have a mechanism for linking to libraries.

> > The ld-options are passed to ghc when it links an executable and they
> > also get included in library package registration information.
> 
> OK, I've attached my cabal file and a transcript of the verbose
> output.
> 
> $ grep string vectro.cabal
> ld-options: this string never appears anywhere as far as i can tell
> $ grep string cabal.out   
> [1]$

Right, since you're making a library ld is never called (it's ar that is
used to make an .a archive file). You should find that the ld-options
have been included in the package registration file, ie if you register
and say: ghc-pkg describe vectro, then you'll see that your ld-options
will get used when linking all programs that use your library.

For your example this is almost certainly not what you want.

So I think the right thing to do is to make an .a archive from your
extra .o files and list that in the extra-libraries: field. You'd need
to arrange for that archive to be installed too. I guess you must have
some outer build system since you're invoking g++ anyway. I'm not sure
how or if you could get cabal to install an extra archive into the right
place. I'm not sure how they do it for the base lib which has this extra
_sbits.a archive. That might be worth looking at.

Perhaps there should be a mechanism to include arbitrary extra .o files
into the archive that cabal produces, but remember that this would be
totally ghc-specific. No other Haskell implementations use archives or
can necessarily link arbitrary .o files.

On the other hand we do already have a mechanism to compile and include
ordinary .c files in a package.

Any cabal devs/users have any opinions on this?

Duncan

From duncan.coutts at worc.ox.ac.uk  Mon Apr 23 03:26:26 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Mon Apr 23 03:24:27 2007
Subject: cabal ignores ld-options?
In-Reply-To: <20070423052024.GL3323@a5.repetae.net>
References: <20070421231118.GA4927@a5.repetae.net>
	<1177227091.7696.21.camel@localhost>
	<20070422105149.GC3323@a5.repetae.net>
	<1177299434.7696.63.camel@localhost>
	<20070423052024.GL3323@a5.repetae.net>
Message-ID: <1177313186.7696.87.camel@localhost>

On Mon, 2007-04-23 at 06:20 +0100, Frederik Eaton wrote:

> > Frederik, in case it's not clear, the reason you're running into
> > problems is because you're doing things people haven't done much before
> > with cabal, that is try and use it as part of a larger multi-language
> > project. I'm not at all saying that's a bad thing, it's just that's why
> > you're noticing these missing features.
> 
> OK, well perhaps a warning in the Cabal documentation is in order:
> "Don't use this system if you need flexibility."

Sure, an explicit statement of coverage, what it does and doesn't handle
yet etc would be a very good thing.


> > Right, since you're making a library ld is never called (it's ar that is
> > used to make an .a archive file). 
> 
> That is not true, both ld and ar are called. See the file named
> cabal.out which I attached to my previous message.

Ah yes I see, but that still would not do what you want. The ar call is
to make the ordinary static lib. The ld call is to make the GHCi .o
equivalent. So if you added a .o file to the ld arguments there but not
for ar then your thing only work with GHCi and not in the normal static
linking case.

> When ld is called, then object files for compiled C files are included
> on the command line (gslaux.o), so I would expect object files for
> compiled C++ files to belong here as well.

Right. As I said we do have a mechanism in Cabal to compile C files and
include them in a package. I was suggesting and asking for feedback on a
similar mechanism to allow arbitrary .o files to be included too.

> If the Cabal documentation were correct, then I think ld-options would
> be what I want.

As I say, it would not be what you want. You need to be able to specify
a bunch of other object files to link in, like we have the c-sources:
field. You'd want other-object-files: or something along those lines.


> > Perhaps there should be a mechanism to include arbitrary extra .o files
> > into the archive that cabal produces, but remember that this would be
> > totally ghc-specific. No other Haskell implementations use archives or
> > can necessarily link arbitrary .o files.
> 
> I see, so FFI in other implementations relies on dynamic or static
> libraries?

I think so but I'm not 100% sure.

> Perhaps I should avoid using Cabal, since it has caused so much
> inefficiency. I will go through cabal.out and put those commands in a
> makefile.

It doesn't scale to have cabal try and build sources from lots of other
languages. C is a special case. If you're doing a multi-language project
you need something else at the top level of your build system. You can
use cabal to build the Haskell part and whatever else to build the other
language stuff. Each can produce their .a / .so files which you install
together or link together.

Duncan

From simonmarhaskell at gmail.com  Mon Apr 23 04:20:26 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Mon Apr 23 04:18:17 2007
Subject: [Fwd: Bug and Features Cabal]
Message-ID: <462C6C4A.50301@gmail.com>

Forwarding on behlaf of Hans van Thiel <hthiel.char@zonnet.nl>.

Hello,

I got this email address from the Cabal documentation page, if it should
be addressed elsewhere, my apologies and please redirect me, if you can.

I'd like to report my experience using Cabal for a simple distribution.

1) building the package according to the instructions worked fine, no
error messages. Uploadig to HackageDB resulted in an error that
the .cabal file could not be found. The reason was its name,
"emping-0.1.cabal", which should have been "Emping-0.1.cabal". Changing
fixed it.
I did not succeed in installing my own program myself with Cabal,
configuration seemed to work fine, but build gave a message that source
files could not be found. I have not tried it yet, but maybe the above
was the problem. (It's not serious, it's a simple utility with no
dependencies and just compiling is sufficient.)

2) the HackageDB test gave warnings that "license-file" and "category"
were missing, warnings which did not occur when building.

3) it is not clear from the Cabal documentation  whether the fields in
the .cabal file are case sensitive or not.

As a feature, I feel that there should be fields for included user
documentation files or directories in the .cabal file. (I even feel they
should be obligatory for all packages.)

The Cabal documentation mentions possible name clashes for packages as a
concern. I tried the Eclipse solution for this, naming the package with
my URL in reverse i.e. "nl.speedlinq.j-van-thiel.emping" but this
resulted in a "parse error". I don't know, but the convention seems to
work well for the Eclipse people. Another possibility might be the use
of a doi (digital object identifier) in the package name? The only
problem is you'd need to get a domain prefix from the current
administration agency, but a doi as unique identifier would also solve
clashes.

Finally, I think Cabal is a great idea and a great help. I hope you will
keep on developing and improving it.

Best Regards,

Hans van Thiel
From ross at soi.city.ac.uk  Mon Apr 23 05:33:45 2007
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Mon Apr 23 05:31:33 2007
Subject: [Fwd: Bug and Features Cabal]
In-Reply-To: <462C6C4A.50301@gmail.com>
References: <462C6C4A.50301@gmail.com>
Message-ID: <20070423093344.GA2483@soi.city.ac.uk>

On Mon, Apr 23, 2007 at 09:20:26AM +0100, Simon Marlow wrote:
> Forwarding on behlaf of Hans van Thiel <hthiel.char@zonnet.nl>.
> [...]
> I did not succeed in installing my own program myself with Cabal,
> configuration seemed to work fine, but build gave a message that source
> files could not be found. I have not tried it yet, but maybe the above
> was the problem. (It's not serious, it's a simple utility with no
> dependencies and just compiling is sufficient.)

The problem is the line "ghc-options: -o".  Perhaps you meant -O (in
future releases of Cabal this will be the default, adjustable from the
configure command line).

Hans has implicitly assumed that the constraints and warnings of
HackageDB should at least trigger warnings when building with Cabal (or
that HackageDB would have no additional constraints).  There's something
to be said for that.  Currently, these are:
 * HackageDB requires that the base name of the .cabal file is identical
   to the name of the package.
 * HackageDB requires that parsing and printing the version number should
   give the original string; this fails for version numbers with redundant
   leading zeroes, like 5.04.
 * In addition to Cabal warnings, HackageDB warns about
    - missing category, description, maintainer and synopsis fields
    - over-long synopsis fields
    - exposed modules that use unallocated top-level names in the module
      hierarchy

From duncan.coutts at worc.ox.ac.uk  Mon Apr 23 06:18:37 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Mon Apr 23 06:16:36 2007
Subject: [Fwd: Bug and Features Cabal]
In-Reply-To: <20070423093344.GA2483@soi.city.ac.uk>
References: <462C6C4A.50301@gmail.com> <20070423093344.GA2483@soi.city.ac.uk>
Message-ID: <1177323518.7696.120.camel@localhost>

On Mon, 2007-04-23 at 10:33 +0100, Ross Paterson wrote:

> Hans has implicitly assumed that the constraints and warnings of
> HackageDB should at least trigger warnings when building with Cabal (or
> that HackageDB would have no additional constraints).  There's something
> to be said for that.  Currently, these are:
>  * HackageDB requires that the base name of the .cabal file is identical
>    to the name of the package.
>  * HackageDB requires that parsing and printing the version number should
>    give the original string; this fails for version numbers with redundant
>    leading zeroes, like 5.04.
>  * In addition to Cabal warnings, HackageDB warns about
>     - missing category, description, maintainer and synopsis fields
>     - over-long synopsis fields
>     - exposed modules that use unallocated top-level names in the module
>       hierarchy

It'd be great to implement this in a Distribution.[Simple.]Lint module
and have HackageDB use that. Additionally we could have "cabal-setup
lint" or "check" or something to get those warnings locally. I'm sure
there are other best practises that we can encode in a bunch of lint
checks.

To advertise itself perhaps we should have cabal-setup sdist suggest
that the user try the lint check. If the user is doing sdist it's likely
that they intend to distribute and it's not just a quick hack so it's a
better time to suggest some QA.

Duncan

From simonmarhaskell at gmail.com  Tue Apr 24 04:45:54 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Tue Apr 24 04:43:43 2007
Subject: Cleaning up hooks
Message-ID: <462DC3C2.30505@gmail.com>

I think the API for hooks is in need of an overhaul.  It has a few problems:

1. it isn't extensible.  When a new command is added, typically
    all the Setup.hs scripts break because they haven't hooked then
    new command.

2. it isn't composable.  It ought to be easy to augment
    PackageDescription in Setup.hs, but it isn't: to do it right,
    you have to modify every hook.

3. It's too complicated.  I'm sure we don't need all those pre- and
    post- hooks.

4. tools that build on Cabal (e.g. cabal-rpm) don't work with hooks.
    If your Setup.hs uses hooks to modify the PackageDescrption, then
    cabal-rpm won't see the modifications.

I can fix 1-3, but 4 is more of a design problem.  I'll outline a possible 
partial solution to 4 later, however.

Anyway, here's the basic idea.  A common thing to want to do in Setup.lhs is to 
modify the PackageDescription, so we provide a way to do that:

modifyPackageDescription
         :: (PackageDescription -> IO PackageDescription)
         -> UserHooks -> UserHooks

modifyPackageDescriptionPostConf
         :: (PackageDescription -> LocalBuildInfo -> IO PackageDescription)
         -> UserHooks -> UserHooks

modifyPackageDescription supplies a function that is run before every command, 
to modify the existing PackageDescription, and it can do IO. 
modifyPackageDescriptionPostConf is similar, except that it does not apply to 
the configure command, and it gets to see the LocalBUildInfo.

These mostly subsume all the preHooks.  For example, 
modifyPackageDescriptionPostConf can be used to read the results of the autoconf 
  script.  (We'll also need to provide a way to merge a new BuildInfo with the 
existing PackageDescription).

The good thing about this is it's extensible and composable.  Adding more 
commands to Cabal won't break Setup.lhs scripts that use these combinators. 
This could also help us solve problem (4) above: Cabal can provide a way to 
output the modified PackageDescription to a file, that can be read in by 
cabal-rpm.  For example, "cabal-setup descr" could output the real 
PackageDescription.

We might still want to hook the real commands, however.  So let's look at 
simplifying the UserHooks type:

  type ConfHook = Args -> ConfigFlags -> PackageDescription -> IO LocalBuildInfo
  type Hook a   = Args -> a -> PackageDescription -> LocalBuildInfo -> IO ()

  data Hooks = Hooks {
   confHook       :: ConfHook,
   postConfHook   :: Hook ConfigFlags
   buildHook      :: Hook BuildFlags,
   makefileHook   :: Hook MakefileFlags,
   cleanHook      :: Hook CleanFlags,
   copyHook       :: Hook CopyFlags,
   installHook    :: Hook InstallFlags,
   sdistHook      :: Hook SDistFlags,
   registerHook   :: Hook RegisterFlags,
   unregisterHook :: Hook UnregisterFlags,
   haddockHook    :: Hook HaddockFlags,
   pfeHook        :: Hook PfeFlags
   }

I've missed out runTests and a few others, but the main idea is that I got rid 
of most the pre- and post-hooks.  The configure command is special, because it 
doesn't see the LocalBuildInfo, so we also need a postConfHook for doing further 
actions after configure (e.g. running the autoconf script).

Suppose we supply thenHook:

  thenHook :: Hook a -> Hook a -> Hook a
  thenHook hook1 hook2 args flags pd lbi = do
    hook1 args flags pd lbi
    hook2 args flags pd lbi

Then to add a post-hook to the build command you could do this:

  addPostBuild :: Hook BuildFlags -> Hooks -> Hooks
  addPostBuild hook hooks
    = hooks { buildHook = buildHook hooks `thenHook` hook }

Alternatively, we could supply addPostBuild, addPreBuild, etc. and hide the 
representation of the Hooks type completely.

Comments?

Cheers,
	Simon

From simonmarhaskell at gmail.com  Tue Apr 24 04:52:44 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Tue Apr 24 04:50:35 2007
Subject: darcs patch: Put pre-processed source into the dist/b... (and
 2	more)
In-Reply-To: <1070422103350.20154@cse.unsw.edu.au>
References: <1070422103350.20154@cse.unsw.edu.au>
Message-ID: <462DC55C.9050502@gmail.com>

Duncan Coutts wrote:
> Those patches I was talking about. I'd apreciate a review :-)

Looks fine - although as we talked about on IRC, we should think carefully about 
what sdist is supposed to do, and the difference between Happy/Alex-generated 
.hs files and c2hs-generated .hs files.  The former should go in an sdist, but 
not the latter.

Cheers,
	Simon
From bos at serpentine.com  Tue Apr 24 13:14:33 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue Apr 24 13:14:13 2007
Subject: [PATCH] initialBuildSteps shouldn't run a complete build
Message-ID: <462E3AF9.7010807@serpentine.com>

Hi, Simon -

The "Setup makefile" refactoring you did was a little over-ambitious, 
and ended up doing a complete serial build before it generated any 
Makefile :-)

	<b
From bos at serpentine.com  Tue Apr 24 13:21:35 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue Apr 24 13:21:15 2007
Subject: [PATCH] initialBuildSteps shouldn't run a complete build
In-Reply-To: <462E3AF9.7010807@serpentine.com>
References: <462E3AF9.7010807@serpentine.com>
Message-ID: <462E3C9F.3060401@serpentine.com>

Bryan O'Sullivan wrote:

> The "Setup makefile" refactoring you did was a little over-ambitious, [...]

As was my bug report, which should have had the following attachment.  Oops!

	<b
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.patch
Type: text/x-patch
Size: 22435 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070424/4c277786/build.bin
From bos at serpentine.com  Tue Apr 24 13:24:33 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue Apr 24 13:24:20 2007
Subject: [RFC] Don't overwrite an existing Makefile
Message-ID: <462E3D51.9010405@serpentine.com>

Hi, Simon -

Another problem with "Setup makefile" is that it will overwrite an 
existing Makefile, even if that file perhaps ought to be present.  For 
example, using "Setup makefile" in a Cabal repo clobbers Cabal's own 
Makefile.

The attached patch causes "Setup makefile" to refuse to overwrite an 
existing file.  I'm a bit ambivalent about it, but I don't see another 
simple, predictable way to avoid the possibility for foot-shooting.

	<b
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile.patch
Type: text/x-patch
Size: 560 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070424/63f8160e/makefile.bin
From bos at serpentine.com  Tue Apr 24 14:40:20 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue Apr 24 14:40:01 2007
Subject: [PATCH] initialBuildSteps shouldn't run a complete build
In-Reply-To: <462E3C9F.3060401@serpentine.com>
References: <462E3AF9.7010807@serpentine.com> <462E3C9F.3060401@serpentine.com>
Message-ID: <462E4F14.7020008@serpentine.com>

Bryan O'Sullivan wrote:

> As was my bug report, which should have had the following attachment.  

That patch trimmed one line too many from initialBuildSteps.  It only 
caused problems with packages containing .hsc files, so I didn't notice 
initially.  Here's a corrected patch.

	<b
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.patch
Type: text/x-patch
Size: 22376 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070424/7d175492/build-0001.bin
From simonmarhaskell at gmail.com  Tue Apr 24 15:48:46 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Tue Apr 24 15:46:39 2007
Subject: [PATCH] initialBuildSteps shouldn't run a complete build
In-Reply-To: <462E3AF9.7010807@serpentine.com>
References: <462E3AF9.7010807@serpentine.com>
Message-ID: <462E5F1E.8000402@gmail.com>

Bryan O'Sullivan wrote:
> Hi, Simon -
> 
> The "Setup makefile" refactoring you did was a little over-ambitious, 
> and ended up doing a complete serial build before it generated any 
> Makefile :-)

In fact it appears that this was the result of Malcolm's recent changes:

Tue Apr 24 11:42:44 BST 2007  Malcolm.Wallace@cs.york.ac.uk
   * pretend that Cabal can build with nhc98

     M ./Distribution/Simple/Build.hs +2

Mon Feb 12 17:14:19 GMT 2007  Malcolm.Wallace@cs.york.ac.uk
   * minor tweaks to nhc98 branches of case distinctions

     M! ./Distribution/Simple/Build.hs -1 +7
     M ./Distribution/Simple/Configure.hs -1 +1
     M ./Distribution/Simple/Install.hs -1 +2
     M ./Distribution/Simple/NHC.hs -8 +13
     M ./Distribution/Simple/Register.hs -1 +5


Anyway I've pushed your patch which looks like the right fix.  Thanks!

Cheers,
	Simon

From duncan.coutts at worc.ox.ac.uk  Tue Apr 24 22:56:46 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Apr 24 22:54:44 2007
Subject: [RFC] Don't overwrite an existing Makefile
In-Reply-To: <462E3D51.9010405@serpentine.com>
References: <462E3D51.9010405@serpentine.com>
Message-ID: <1177469806.21687.1.camel@localhost>

On Tue, 2007-04-24 at 10:24 -0700, Bryan O'Sullivan wrote:
> Hi, Simon -
> 
> Another problem with "Setup makefile" is that it will overwrite an 
> existing Makefile, even if that file perhaps ought to be present.  For 
> example, using "Setup makefile" in a Cabal repo clobbers Cabal's own 
> Makefile.
> 
> The attached patch causes "Setup makefile" to refuse to overwrite an 
> existing file.  I'm a bit ambivalent about it, but I don't see another 
> simple, predictable way to avoid the possibility for foot-shooting.

That sounds reasonable to me. Any objections? If not I'll apply it.

Duncan

From duncan.coutts at worc.ox.ac.uk  Tue Apr 24 22:59:15 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Apr 24 22:57:14 2007
Subject: darcs patch: Put pre-processed source into the dist/b... (and
	2	more)
In-Reply-To: <462DC55C.9050502@gmail.com>
References: <1070422103350.20154@cse.unsw.edu.au> <462DC55C.9050502@gmail.com>
Message-ID: <1177469956.21687.4.camel@localhost>

On Tue, 2007-04-24 at 09:52 +0100, Simon Marlow wrote:
> Duncan Coutts wrote:
> > Those patches I was talking about. I'd apreciate a review :-)
> 
> Looks fine - although as we talked about on IRC, we should think carefully about 
> what sdist is supposed to do, and the difference between Happy/Alex-generated 
> .hs files and c2hs-generated .hs files.  The former should go in an sdist, but 
> not the latter.

Indeed. We need to know for each pre-processor if the generated .hs
files are platform and implementation independent. As Ross points out,
currently we don't do anything about implementation independence, we
generate alex & happy .hs files that use ghc extensions and then include
them in the sdist tarball.

Duncan

From simonmarhaskell at gmail.com  Wed Apr 25 03:43:07 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Wed Apr 25 03:40:52 2007
Subject: [RFC] Don't overwrite an existing Makefile
In-Reply-To: <1177469806.21687.1.camel@localhost>
References: <462E3D51.9010405@serpentine.com>
	<1177469806.21687.1.camel@localhost>
Message-ID: <462F068B.1030106@gmail.com>

Duncan Coutts wrote:
> On Tue, 2007-04-24 at 10:24 -0700, Bryan O'Sullivan wrote:
>> Hi, Simon -
>>
>> Another problem with "Setup makefile" is that it will overwrite an 
>> existing Makefile, even if that file perhaps ought to be present.  For 
>> example, using "Setup makefile" in a Cabal repo clobbers Cabal's own 
>> Makefile.
>>
>> The attached patch causes "Setup makefile" to refuse to overwrite an 
>> existing file.  I'm a bit ambivalent about it, but I don't see another 
>> simple, predictable way to avoid the possibility for foot-shooting.
> 
> That sounds reasonable to me. Any objections? If not I'll apply it.

Sure, go ahead.  I was meaning to get around to that sometime.

Cheers,
	Simon
From igloo at earth.li  Wed Apr 25 07:56:27 2007
From: igloo at earth.li (Ian Lynagh)
Date: Wed Apr 25 07:54:09 2007
Subject: darcs patch: If "Setup configure" can't satisfy deps set
	buildable=...
Message-ID: <E1Hgg6l-0001b8-9T@matrix.matrix.chaos.earth.li>

Wed Apr 25 12:33:09 BST 2007  Ian Lynagh <igloo@earth.li>
  * If "Setup configure" can't satisfy deps set buildable=False rather than failing
  Before there was an odd inconsistency, where ./configure scripts would
  (on failure) set buildable=False in <package>.buildinfo and return
  successfully, but if "Setup configure" itself failed due to missing
  build-deps then it would just exit unsuccessfully.
  
  This patch, based on a suggestion from Claus Reinke, makes "Setup configure"
  behave like ./configure.
  
  writeHookedBuildInfo is a bit of a misnomer for this use, but it'll do what
  we need.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 25183 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070425/9a65787d/attachment-0001.bin
From simonmarhaskell at gmail.com  Thu Apr 26 03:52:08 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Thu Apr 26 03:49:50 2007
Subject: Integrating Cabal, Haddock, HsColour
In-Reply-To: <462A7532.60402@di.unipi.it>
References: <462A7532.60402@di.unipi.it>
Message-ID: <46305A28.1080102@gmail.com>

Roberto Zunino wrote:
> I've just extended Cabal so to generate docs with links to highlighted
> sources. Now
> 
> ./Setup configure
> ./Setup haddock --link-to-hscolour
> ./Setup hscolour --css my_own_stylesheet.css
> 
> generates HTML as this one: (run on Cabal itself)
> 
> http://www.di.unipi.it/~zunino/tmp/dist/doc/html/Cabal/Distribution-Program.html#v%3AwithProgramFlag
> 
> Click on the "Source" links on the right. You will be sent to the exact
> line. The whole Cabal docs+sources are online. Colours have been chosen
> to match my emacs configuration :-P .
> 
> This relies on a couple of minor tweaks to Haddock and HsColour which I
> darcs-sent this morning to the authors.
> 
> Comments are welcome.
> 
> - Is this worth including in the next Cabal version?

Looks really nice!  (BTW, cabal-devel@haskell.org is a better place to discuss 
Cabal improvements).

I'm happy for it to go in.

> - Are the options above good choices?

I'd make 'Setup haddock --hscolour' do both steps.

> - Is the directory tree OK? Currently Haddock creates (under dist/doc/html)

Looks fine.

Cheers,
	Simon
From duncan.coutts at worc.ox.ac.uk  Mon Apr 30 16:38:29 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Mon Apr 30 16:48:36 2007
Subject: [RFC] Don't overwrite an existing Makefile
In-Reply-To: <462E3D51.9010405@serpentine.com>
References: <462E3D51.9010405@serpentine.com>
Message-ID: <1177965509.6211.83.camel@localhost>

On Tue, 2007-04-24 at 10:24 -0700, Bryan O'Sullivan wrote:
> Hi, Simon -
> 
> Another problem with "Setup makefile" is that it will overwrite an 
> existing Makefile, even if that file perhaps ought to be present.  For 
> example, using "Setup makefile" in a Cabal repo clobbers Cabal's own 
> Makefile.
> 
> The attached patch causes "Setup makefile" to refuse to overwrite an 
> existing file.  I'm a bit ambivalent about it, but I don't see another 
> simple, predictable way to avoid the possibility for foot-shooting.

Applied.

Btw, it's a little easier if you send darcs patches rather than
diff-style patches. Plus you get your name properly recorded in the
darcs changelog! :-) (rather than just in the commit message)

Duncan

From duncan.coutts at worc.ox.ac.uk  Mon Apr 30 16:48:18 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Mon Apr 30 16:58:23 2007
Subject: darcs patch: If "Setup configure" can't satisfy deps set
	buildable=...
In-Reply-To: <E1Hgg6l-0001b8-9T@matrix.matrix.chaos.earth.li>
References: <E1Hgg6l-0001b8-9T@matrix.matrix.chaos.earth.li>
Message-ID: <1177966098.6211.87.camel@localhost>

After talking to Ian we decided to do this differently. setup configure
should just fail if the package cannot build, and furthermore any
autoconf ./configure scripts should also fail if they detect situations
where the package will not be buildable.

GHC's libraries build system can just use setup configure failing as an
indication that the package should be skipped.

Duncan

On Wed, 2007-04-25 at 12:56 +0100, Ian Lynagh wrote:
> Wed Apr 25 12:33:09 BST 2007  Ian Lynagh <igloo@earth.li>
>   * If "Setup configure" can't satisfy deps set buildable=False rather than failing
>   Before there was an odd inconsistency, where ./configure scripts would
>   (on failure) set buildable=False in <package>.buildinfo and return
>   successfully, but if "Setup configure" itself failed due to missing
>   build-deps then it would just exit unsuccessfully.
>   
>   This patch, based on a suggestion from Claus Reinke, makes "Setup configure"
>   behave like ./configure.
>   
>   writeHookedBuildInfo is a bit of a misnomer for this use, but it'll do what
>   we need.


From bos at serpentine.com  Mon Apr 30 17:03:50 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Mon Apr 30 17:04:10 2007
Subject: [RFC] Don't overwrite an existing Makefile
In-Reply-To: <1177965509.6211.83.camel@localhost>
References: <462E3D51.9010405@serpentine.com>
	<1177965509.6211.83.camel@localhost>
Message-ID: <463659B6.2020303@serpentine.com>

Duncan Coutts wrote:

> Btw, it's a little easier if you send darcs patches rather than
> diff-style patches.

Oh yes.  I just wasn't sure this patch was the right approach :-)

	<b