- cabal-devel - Haskell.org

Cleaning .x and .y files
by Ian Lynagh 17 Oct '06

17 Oct '06

Hi all, I think Duncan has already said that we need a way to have .x and .y files included in sdists, but we also need a clean variant or flag that doesn't clean them. Apologies if this has also already been pointed out and I missed it. Thanks

2 1

Escaping when generating register.sh
by Ian Lynagh 16 Oct '06

16 Oct '06

Hi all, The register.sh script generated by runhaskell Setup.hs register --gen-script with Cabal 1.16 is not escaping quotes correctly, e.g. with the OpenGL package in extralibs it contains echo 'name: OpenGL [...] OpenGL is the industry's most widely used and supported 2D and 3D [ ^^^ ] [...] haddock-html: /usr/share/OpenGL-2.1/doc/html' | /usr/bin/ghc-pkg update - Thanks Ian

2 1

Re: Haddock source tar file name
by Duncan Coutts 16 Oct '06

16 Oct '06

On Mon, 2006-10-16 at 12:36 +0100, Simon Marlow wrote: > Sven Panne wrote: > > I've just seen that the .spec file has been changed for Haddock 0.8, but I am > > a bit unhappy about that change. The change was that the source tar file is > > not "haddock-0.8.tar.gz" anymore, but "haddock-0.8-src.tar.gz". Although I > > can partly understand the reasoning behind the "-src", I'd like to vote > > against this change for the simple reason that Cabal's sdist does not use it > > and generates the "old" name. Therefore I have reverted the patch vote for > > repackaging Haddock 0.8 before it's too late and confusion arises. Let's > > fully use Cabal for building the source distributions and binaries without > > any obscure special cases... > > > > I would have objected earlier, but the commits/pushes to the tools don't cause > > a commit email. Could this be changed, too? > > Thanks for pointing this out. I didn't use sdist to produce the Haddock 0.8 > distributions, but I will for the next release, and I'll make sure this problem > doesn't crop up with the Happy & Alex releases. And if anyone wants to make cabal's sdist include pre-built .hs versions of happy/alex .y/.x files then that'd be great. Currently that's a manual step. Duncan

1 0

ANNOUNCE: Cabal version 1.1.6
by Duncan Coutts 11 Oct '06

11 Oct '06

The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://haskell.org/cabal/ Cabal version 1.1.6 is now available. It is included in GHC version 6.6. For other Haskell implementations or older versions of GHC you can install it separately: DOWNLOAD: http://www.haskell.org/cabal/download.html http://www.haskell.org/cabal/release/latest/cabal-1.1.6.tar.gz DOCUMENTATION: http://www.haskell.org/cabal/release/latest/doc/users-guide/ http://www.haskell.org/cabal/release/latest/doc/API/ See both the README file and the changelog for interface changes: http://www.haskell.org/cabal/release/latest/changelog BUGS: Report bugs using our bug tracker: http://hackage.haskell.org/trac/hackage/newticket or to the libraries(a)haskell.org mailing list.

1 0

4th Cabal-1.1.6 release candiate
by Duncan Coutts 10 Oct '06

10 Oct '06

Hi all, I've put up a tarball for the fourth 1.16 Cabal release candidate: http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz I had been hoping that this would be the final RC. One bug I've uncovered is that building the haddock docs for HUnit when cpphs is installed fails. This is because the Distribution.PreProcess.Unlit.unlit code produces incorrect output for Test/HUnit/Lang.lhs. I could do with some help in fixing this. One can reproduce it with: cd libraries/HUnit cpphs -OLang.lhs Test/HUnit/Lang.lhs --noline --strip -D__GLASGOW_HASKELL__=605 -D__HADDOCK__ ghc -e 'interact (Distribution.PreProcess.Unlit.unlit "Lang.lhs")' < Lang.lhs > Lang.hs compare this with: ghc -E Lang.lhs -o Lang.hspp and try: diff Lang.hspp Lang.hs Cabal's unlit code is incorrectly dropping whitespace and actual tokens. See especially the last part of that file. I think this needs fixing asap since the cpphs code path gets used in preference to the ghc -E path if cpphs is installed. In this example the symptoms are not too bad as it seems only to be affecting haddock, but I fear it may break more seriously in other packages. Duncan

2 3

Problem linking on Win32
by Jason Dagit 09 Oct '06

09 Oct '06

Hello, I have a program and I'd like to permanently change the default RTS options. According to the GHC manual I can do that by linking with a snippet of C code: http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html Look at section 4.14.5 at the bottom of the page. I can't seem to get cabal to link my program together so that my custom rts options take affect. To help demonstrate I've created a minimal test case: ------------- oom.cabal ------------------- name: OutOfMemory version: 0.1 cabal-version: -any license: AllRightsReserved license-file: "" build-depends: base -any c-sources: rtsoptions.c exposed-modules: Main Executable: oom Main-is: Main.hs ------------- end oom.cabal ----------- --------------- Main.hs --------------------- module Main where main :: IO () main = print $ foldl (+) 0 [1..100000000] --------------- End Main.hs -------------- /* rtsoptions.c */ char *ghc_rts_opts = "-M1024M -K256M"; /* end rtsoptions.c */ Also using the standard Setup.lhs: #! /usr/bin/runghc \begin{code} import Distribution.Simple main = defaultMain \end{code} When build and run this I get: C:\projects\tmp>runghc Setup.lhs build Preprocessing library OutOfMemory-0.1... Preprocessing executables for OutOfMemory-0.1... Building OutOfMemory-0.1... [1 of 1] Compiling Main ( Main.hs, dist\build\oom\oom-tmp/Main.o ) Linking dist\build\oom\oom.exe ... C:\projects\tmp>dist\build\oom\oom.exe Heap exhausted; Current maximum heap size is 268435456 bytes (256 Mb); use `+RTS -M<size>' to increase it. On the other hand, if I build rtsoptions.c manually and add it to the ghc-options line in the .cabal file it does build and run until in needs more than 976Mb (showing that the default RTS options are indeed different). Below is the trace of the build process: Preprocessing library OutOfMemory-0.1... Preprocessing executables for OutOfMemory-0.1... Building OutOfMemory-0.1... Building library... Building C Sources... C:\Program Files\Visual Haskell\bin\ghc.exe -odir dist\build -hidir dist\build -c -v rtsoptions.c Glasgow Haskell Compiler, Version 6.5, for Haskell 98, compiled by GHC version 6.5 Using package config file: C:\Program Files\Visual Haskell\package.conf Hsc static flags: -static *** C Compiler: C:\Program Files\Visual Haskell\gcc -BC:\Program Files\Visual Haskell\gcc-lib/ -x c rtsoptions.c -o C:\DOCUME~1\JASOND~1\LOCALS~1\Temp\ghc528_0.s -DDONT_WANT_WIN32_DLL_SUPPORT -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=605 -I C:/Program Files/Visual Haskell\include -I C:/Program Files/Visual Haskell\include\mingw Reading specs from C:/Program Files/Visual Haskell/gcc-lib/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-exceptions Thread model: win32 gcc version 3.2.3 (mingw special 20030504-1) C:\Program Files\Visual Haskell\gcc-lib\cc1.exe -lang-c -v -I C:/Program Files/Visual Haskell\include -I C:/Program Files/Visual Haskell\include\mingw -iprefix C:\Program Files\Visual Haskell\../lib/gcc-lib/mingw32/3.2.3/ -isystem C:/Program Files/Visual Haskell/gcc-lib/include -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D_WIN32 -D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -D__MSVCRT__ -DWINNT -D_X86_=1 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__WIN32 -D__WINNT -Asystem=winnt -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__fastcall=__attribute__((__fastcall__)) -D_stdcall=__attribute__((__stdcall__)) -D_cdecl=__attribute__((__cdecl__)) -D_fastcall=__attribute__((__fastcall__)) -D__declspec(x)=__attribute__((x)) -DDONT_WANT_WIN32_DLL_SUPPORT -D__GLASGOW_HASKELL__=605 rtsoptions.c -quiet -dumpbase rtsoptions.c -O -Wimplicit -version -o C:\DOCUME~1\JASOND~1\LOCALS~1\Temp\ghc528_0.s GNU CPP version 3.2.3 (mingw special 20030504-1) (cpplib) (80386, BSD syntax) GNU C version 3.2.3 (mingw special 20030504-1) (mingw32) compiled by GNU C version 3.2.3 (mingw special). ignoring nonexistent directory "C:/Program Files/lib/gcc-lib/mingw32/3.2.3/../../../../include" ignoring nonexistent directory "C:/Program Files/lib/gcc-lib/mingw32/3.2.3/include" ignoring nonexistent directory "C:/Program Files/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/include" ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.2.3/include" ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/include" ignoring nonexistent directory "/usr/local/mingw32/include" #include "..." search starts here: #include <...> search starts here: C:/Program Files/Visual Haskell/include C:/Program Files/Visual Haskell/include/mingw C:/Program Files/Visual Haskell/gcc-lib/include /mingw/lib/gcc-lib/mingw32/3.2.3/../../../../include /mingw/include End of search list. *** Assembler: C:\Program Files\Visual Haskell\gcc -BC:\Program Files\Visual Haskell\gcc-lib/ -c C:\DOCUME~1\JASOND~1\LOCALS~1\Temp\ghc528_0.s -o dist\build\rtsoptions.o *** Deleting temp files: Deleting: C:/DOCUME~1/JASOND~1/LOCALS~1/Temp/ghc528_0.s cabal-linking... C:\Program Files\Visual Haskell\bin\ar.exe qv dist\build\libHSOutOfMemory-0.1.a dist\build\rtsoptions.o a - dist\build\rtsoptions.o C:\Program Files\Visual Haskell\gcc-lib\ld.exe -r -x -o dist\build\HSOutOfMemory-0.1.o dist\build\rtsoptions.o Building executable: oom... C:\Program Files\Visual Haskell\bin\ghc.exe -Idist\build -o dist\build\oom\oom --make -v -hide-all-packages -i -idist\build\autogen -i. -odir dist\build\oom\oom-tmp -hidir dist\build\oom\oom-tmp -package base-1.0 Main.hs Glasgow Haskell Compiler, Version 6.5, for Haskell 98, compiled by GHC version 6.5 Using package config file: C:\Program Files\Visual Haskell\package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Main.hs Stable obj: [] Stable BCO: [] compile: input file Main.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( Main.hs, dist\build\oom\oom-tmp/Main.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 61 *** Simplify: Result size = 124 Result size = 108 Result size = 108 *** Tidy Core: Result size = 108 *** CorePrep: Result size = 118 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: C:\Program Files\Visual Haskell\gcc -BC:\Program Files\Visual Haskell\gcc-lib/ -I. -Idist\build -c C:\DOCUME~1\JASOND~1\LOCALS~1\Temp\ghc2924_0.s -o dist\build\oom\oom-tmp\Main.o *** Deleting temp files: Deleting: C:/DOCUME~1/JASOND~1/LOCALS~1/Temp/ghc2924_0.s Upsweep completely successful. *** Deleting temp files: Deleting: link: linkables are ... LinkableM (Mon Oct 9 11:28:19 Pacific Standard Time 2006) Main [DotO dist\build\oom\oom-tmp/Main.o] Linking dist\build\oom\oom.exe ... *** Linker: C:\Program Files\Visual Haskell\gcc -BC:\Program Files\Visual Haskell\gcc-lib/ -v -o dist\build\oom\oom.exe -DDONT_WANT_WIN32_DLL_SUPPORT dist\build\oom\oom-tmp/Main.o -LC:/Program Files/Visual Haskell -LC:/Program Files/Visual Haskell\gcc-lib -lHSbase -lHSbase_cbits -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -u _GHCziBase_Izh_static_info -u _GHCziBase_Czh_static_info -u _GHCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u _GHCziPtr_Ptr_static_info -u _GHCziWord_Wzh_static_info -u _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_info -u _GHCziInt_I64zh_static_info -u _GHCziWord_W8zh_static_info -u _GHCziWord_W16zh_static_info -u _GHCziWord_W32zh_static_info -u _GHCziWord_W64zh_static_info -u _GHCziStable_StablePtr_static_info -u _GHCziBase_Izh_con_info -u _GHCziBase_Czh_con_info -u _GHCziFloat_Fzh_con_info -u _GHCziFloat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u _GHCziPtr_FunPtr_con_info -u _GHCziStable_StablePtr_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u _GHCziPack_unpackCString_closure -u _GHCziIOBase_stackOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u _GHCziIOBase_NonTermination_closure -u _GHCziIOBase_BlockedOnDeadMVar_closure -u _GHCziIOBase_BlockedIndefinitely_closure -u _GHCziIOBase_Deadlock_closure -u _GHCziIOBase_NestedAtomically_closure -u _GHCziWeak_runFinalizzerBatch_closure Reading specs from C:/Program Files/Visual Haskell/gcc-lib/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-exceptions Thread model: win32 gcc version 3.2.3 (mingw special 20030504-1) C:\Program Files\Visual Haskell\gcc-lib\ld.exe -Bdynamic -o dist\build\oom\oom.exe -u _GHCziBase_Izh_static_info -u _GHCziBase_Czh_static_info -u _GHCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u _GHCziPtr_Ptr_static_info -u _GHCziWord_Wzh_static_info -u _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_info -u _GHCziInt_I64zh_static_info -u _GHCziWord_W8zh_static_info -u _GHCziWord_W16zh_static_info -u _GHCziWord_W32zh_static_info -u _GHCziWord_W64zh_static_info -u _GHCziStable_StablePtr_static_info -u _GHCziBase_Izh_con_info -u _GHCziBase_Czh_con_info -u _GHCziFloat_Fzh_con_info -u _GHCziFloat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u _GHCziPtr_FunPtr_con_info -u _GHCziStable_StablePtr_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u _GHCziPack_unpackCString_closure -u _GHCziIOBase_stackOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u _GHCziIOBase_NonTermination_closure -u _GHCziIOBase_BlockedOnDeadMVar_closure -u _GHCziIOBase_BlockedIndefinitely_closure -u _GHCziIOBase_Deadlock_closure -u _GHCziIOBase_NestedAtomically_closure -u _GHCziWeak_runFinalizzerBatch_closure C:/Program Files/Visual Haskell/gcc-lib/crt2.o C:/Program Files/Visual Haskell/gcc-lib/crtbegin.o -LC:/Program Files/Visual Haskell -LC:/Program Files/Visual Haskell\gcc-lib -LC:/Program Files/Visual Haskell/gcc-lib -L/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib -L/mingw/lib/gcc-lib/mingw32/3.2.3/../../.. dist\build\oom\oom-tmp/Main.o -lHSbase -lHSbase_cbits -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt C:/Program Files/Visual Haskell/gcc-lib/crtend.o link: done *** Deleting temp files: Deleting: Thanks, Jason

2 4

Re: 4th Cabal-1.1.6 release candiate
by Duncan Coutts 09 Oct '06

09 Oct '06

On Mon, 2006-10-09 at 12:33 +0100, Malcolm Wallace wrote: > Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> wrote: > > > building the haddock docs for HUnit when cpphs is > > installed fails. This is because the > > Distribution.PreProcess.Unlit.unlit code produces incorrect output for > > Test/HUnit/Lang.lhs. > > > > I could do with some help in fixing this. > > You could try using the --unlit option of cpphs, That sounds like a good plan. > which gives correct output, instead of the broken code in > Distribution.PreProcess.Unlit.unlit. I think the Distribution.PreProcess.Unlit module was taken from an early version of cpphs. One possibility would be to update to the latest cpphs unlit code, but for that of course we'd need your permission as the copyright licenses are different. > This requires cpphs >= 1.2, which was released in May this year. Is there anyway to identify the cpphs version from running it? I don't see any --version flag or similar. I'm wondering how cabal is going to be able to identify if the user has a sufficiently recent version. Duncan

1 0

Re: Building extra-libs using Cabal
by Duncan Coutts 04 Oct '06

04 Oct '06

On Tue, 2006-10-03 at 00:07 +0100, Ross Paterson wrote: > On Thu, Sep 28, 2006 at 11:34:08AM +0100, Ross Paterson wrote: > > On Thu, Sep 28, 2006 at 11:19:42AM +0100, Simon Peyton-Jones wrote: > > > The relevant packages are: > > > > > > Haddock errors: http://hackage.haskell.org/trac/ghc/ticket/894 > > > network > > > xhtml > > > opengl > > > openal > > > alut > > > > xhtml is fixed. The others (plus GLUT, I think) are a Cabal problem. > > To elaborate, when cpphs is called from the haddock phase, it's not > passed the cpp arguments that are used by build. I think Cabal needs > a cpp-options field, for cpp options needed for Haskell source. They're > currently in cc-options or compiler-specific option fields, but they > don't really belong there. Yes, Lennart Kolmodin was just investigating this problem for Gentoo and came to a similar conclusion. We can't pass all the cc-options to hsc2hs or cpphs, we'd have to filter them which seems a bit ugly. The other ugly option is to add these flags to ghc-options. Anyone got a suggestion for what to do in the short term (ie the 1 week 'til the ghc & cabal release) ? Duncan

1 1

Haskell Packages 6.6?
by Isaac Jones 04 Oct '06

04 Oct '06

Hello good Haskell Hackers. We're pretty well along the way to getting cabal-install and friends working nicely. We've got almost 30 packages in the database. Let's imagine something that would be awesome. A set of Haskell packages which are all known to work together with a particular version of cabal (the one that GHC comes with), and a particular version of GHC. GHC version 6.6 will be released soon, and I think we should try to make this happen. Currently, we have a set of 27 "unstable" packages. They may or may not work with each-other and such: http://hackage.haskell.org/packages/ I just created an empty directory "testing". I propose that we start testing packages, starting with the cabal release candidate that'll go into GHC 6.6, and make sure they work nicely together. Once they're known to work, we can migrate them from the "unstable" directory to the "testing" directory. Once we have a sufficient collection of packages, and once ghc 6.6 is released, we can make a snapshot of this directory, call it "stable-6.6" or something. Then if you have ghc 6.6 and cabal-install, you should be able to "cabal-install p" for any package, and it'll definitely work. So what will we need for this to happen? 1. An installed version of ghc 6.6 on the hackage/darcs server. Maybe in a chroot or something. Maybe from the nightly build tree or the previous snapshot? 2. Some initial set of packages (maybe just cabal-install) to start off. 3. Some script that goes through and builds all of the "unstable" packages in dependency order. I think cabal-install can do this already. In fact, it would be ideal if we used cabal-install for this. 4. The script should also run ./setup haddock and ./setup test. If the packages seem to work w/ 6.6 and the other packages in "testing", it should get migrated from "unstable" to "testing". 5. A web interface (lemmih is working on it) 6. A script to upload packages to "unstable" (Paolo is working on it). 7. Someone to spearhead all of this! peace, isaac p.s. here are the packages we have currently in the database: parsedate-2006.6.4 Haskell library for parsing dates and times cgi-2006.8.5 A Haskell library for writing CGI programs HDBC-odbc-1.0.1.0 lambdabot-4.0 bzlib-0.2 Compression and decompression in the bzip2 format HDBC-sqlite3-1.0.1.0 hask-home-2006.3.23 Generate homepages for cabal packages XmlRpc-2006.6.26 hnop-0.1 Haskell No Operation fps-0.7 HDBC-postgresql-1.0.1.0 rss-2006.7.12 A library for generating RSS 2.0 feeds. HTTP-2006.7.7 Crypto-3.0.3 DES, Blowfish, AES, SHA1, MD5, RSA, X.509 Identity and Attribute Certificates, General ASN.1 Support, Base64, PKCS8, PKCS1v15, Hexdump, Support for Word128, Word192 and Word256 and Beyond, PKCS5 Padding, Various Encryption Modes e.g. Cipher Block Chaining all in one package.plugins-1.0 fastcgi-2006.8.5 A Haskell library for writing FastCGI programs zlib-0.2 Compression and decompression in the gzip and zlib formats HDBC-1.0.1 xhtml-2006.7.5 A Haskell XHTML combinator library darcs-graph-0.1 gd-2006.7.12 A Haskell binding to a subset of the GD graphics library hmp3-1.1 Djinn-2005.12.14 A haskell proof generator iconv-0.2 Perform character set conversion exif-2006.7.11 A Haskell binding to a subset of libexif HaXml-1.13.1 Utilities for manipulating XML documents

2 2

sof patch for --ghc-pkg-config-file=
by Isaac Jones 29 Sep '06

29 Sep '06

Emailing to libraries@, please followup to cabal-devel. Here's a patch from Sigbjorn which adds --ghc-pkg-config-file= to cabal. This is an oldish patch, but I haven't stopped getting requests for this feature :) This allows you to create a "local" package config file, rather than using the --user or --global files, this is useful for in-place building, as when you're developing a set of related packages. I still have some debate about whether this patch should go in; it assumes a model of package registration where you have a config file (as opposed to a directory) which isn't the case for nhc or Hugs. But the idea doesn't seem to bother anyone but me, and the flag is clearly marked as a ghc-related flag, so I'm thinking of letting it through. Opinions? Does anyone want to massage this to work w/ the current cabal head? peace, isaac ------------------------------------------------------------ Changed paths: M /Distribution/Make.hs M /Distribution/Setup.hs M /Distribution/Simple/Build.hs M /Distribution/Simple/Configure.hs M /Distribution/Simple/GHCPackageConfig.hs M /Distribution/Simple/Install.hs M /Distribution/Simple/LocalBuildInfo.hs M /Distribution/Simple/Register.hs M /Distribution/Simple.hs M /tests/ModuleTest.hs A couple of extensions: - support for specifying what GHC package configuration file to use during (un)registration. Specified via the command-line option --ghc-pkg-config-file=<path> which is understood by 'configure', 'install', 'register', and 'unregister' commands. - better handling of package-specific header files during installation. If you use the Include-Dirs: and Includes: fields in your .cabal file to refer to package-local header files and directories, these will be created&copied during 'install'. i.e., suppose you spec the following: Include-Dirs: /usr/local/include/openssl, include Includes: include/openssl-exts.h, +openssl/openssl.h The 'install' action will emit the following ghc-pkg fields when updating/installing the GHC package: include_dirs = [ "/usr/local/include/openssl", "/path/to/your/pkg/installation/lib/directory/include"] c_includes = [ "openssl-exts.h", "openssl/openssl.h"] and creates the directory in include_dirs's second element, followed by copying openssl-exts.h into that directory. Note: - only directories that don't start with '/' are created inside the package's install directory. - Includes: entries that are prefixed with '+' are assumed to be referring to non-package header files and aren't (attempted) copied into the package's installation tree. Bit of a twiddly hack, but supporting the distinction between package and non-package header files does seem to be necessary.

4 6