December 2007 - cabal-devel

Re: [Hackage] #103: feature request: preprocess files with ghc before haddock?
by Hackage 30 Dec '07

30 Dec '07

#103: feature request: preprocess files with ghc before haddock? -------------------------------+-------------------------------------------- Reporter: newsham(a)lava.net | Owner: ijones Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.1.6 Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -------------------------------+-------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => wontfix Comment: Definitely not something we can fix in Cabal. Requires a feature in ghc and/or haddock-2.0. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/103#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Coping with weirdo third party packages
by Bryan O'Sullivan 30 Dec '07

30 Dec '07

As part of the LLVM stuff, I've run into a few more stumbling blocks. 1. "ghc-options" only seems to be passed to GHC during compilation of a library, not at link time when building an executable against an installed copy of the library. As LLVM is written in C++, I need to link using the C++ compiler instead of the C compiler. I'd like to get "-pgml g++" into the linking phase somehow. 2. LLVM has some slightly unusual code building conventions: some code is shipped as .o files, with the expectation that a program will do something like this at link time: g++ -o foo foo.o `llvm-config --ldflags --libs engine` The llvm-config command prints stuff like this: $ llvm-config --libs engine /usr/lib/LLVMInterpreter.o /usr/lib/LLVMExecutionEngine.o -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMbzip2 -lLLVMSystem Notice the absolute paths to .o files in there. I had hoped to be able to use Cabal to avoid the need for a user to run llvm-config --ldflags or --libs, but I can't list the .o files in the extra-libraries section, because Cabal slaps a "-l" in front: /usr/bin/ld: cannot find -l/usr/lib/LLVMExecutionEngine.o This could be patched easily enough. 3. It would also be nice to have a leading "-l" stripped off if present, the better to feed the output of llvm-config directly into a .buildinfo file without stuffing it through sed first. Cabaliers, would you like some patches for 2 and 3 above? What should we do about 1? <b

2 5

Can't upload a newish package
by Bryan O'Sullivan 30 Dec '07

30 Dec '07

I'm using ghc 6.8.2, and can't upload the LLVM bindings from http://darcs.serpentine.com/llvm/ Here's the error I get from "cabal-upload -v": line 41: Parse of field 'extensions' failed: Unfortunately, it includes no further details. And here's the extensions section from the .cabal file: extensions: EmptyDataDecls FlexibleInstances ForeignFunctionInterface GeneralizedNewtypeDeriving TypeOperators TypeSynonymInstances

2 1

patch applied (cabal): Set dynlibdir to $libdir per default.
by Duncan Coutts 29 Dec '07

29 Dec '07

Fri Dec 28 10:36:04 PST 2007 Clemens Fruhwirth <clemens(a)endorphin.org> * Set dynlibdir to $libdir per default. M ./Distribution/Simple/InstallDirs.hs -2 +2

1 0

Re: [Hackage] #34: specify a way to add .o files to a library
by Hackage 29 Dec '07

29 Dec '07

#34: specify a way to add .o files to a library ----------------------------+----------------------------------------------- Reporter: igloo | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Comment (by duncan): This would not work at all well with a dependency system since we want to know there how to generate or re-generate the .o files rather than just rely on sequencing. On the other hand in the new dependency system it should be easy to add extra ways of generating .o files in a hook. So I think we should wait and revisit this issue when developing the dependency framework. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/34#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: patch applied (cabal): make rawSystemStdout put its temp files in the temp dir rather than cwd
by Duncan Coutts 29 Dec '07

29 Dec '07

On Fri, 2007-12-28 at 09:54 -0500, Gregory Wright wrote: > Hi Duncan, > > (Cross-posting to ghc-users since some of the issues were brought up > there.) > > On Dec 2, 2007, at 5:04 PM, Duncan Coutts wrote: > > > Sun Dec 2 14:06:20 PST 2007 Duncan Coutts <duncan(a)haskell.org> > > * make rawSystemStdout put its temp files in the temp dir rather > > than cwd > > Should fixe reported wierdness with finding program version numbers > > > > M ./Distribution/Simple/Utils.hs -2 +4 > > > > I saw this problem when trying to build 6.8.1 on a mac (Leopard/Intel) > using 6.4 to build compiler. I edited rawSystemStdout to put the tmp > files directory in "/tmp" instead of using getTemporaryDirectory. On > this combination of compilers, moving the temporary file did not fix > the problem of finding the program version number. The underlying > error was that the temp file was reported to still be locked. I've no idea what the problem could be but I would not expect changing the directory where the temp files are put to be related. What can cause file locked errors? I thought the OS did not enforce any locking and it was only the RTS that did so, and only within a process, not between processes using OS voluntary locking apis. As far as I know, only Windows enforces these kinds of file locks (like preventing deleting of open files). > Building 6.8.2 with another 6.8.2 eliminated the program version > problem, but I have seen two other intermittent errors which seem to > be related. (Reported in trac as issue #1992.) Building 6.8.2 with > 6.8.2 using the MacPorts infrastructure, I get this error about half > the time: > ../compiler/stage1/ghc-inplace -M -optdep-f -optdep.depend-BASE - > osuf o -I../includes -H16m -O -I/opt/local/include -I/usr/include -L/ [snip] > .depend-BASE: openFile: resource busy (file is locked) Cabal never directly calls ghc to generate Makefile style dependencies, though ghc's build system does use Cabal to generate Makefiles which call ghc to generate .depend files. > When I build in an eshell running under Aquamacs, I've consistently > had the build fail with: > > ../utils/mkdependC/mkdependC -f .depend-BASE -D__GLASGOW_HASKELL__=608 > -I../includes -Iutils -IbasicTypes -Itypes -IhsSyn -Iprelude -Irename - > Itypecheck -IdeSugar -IcoreSyn -Ivectorise -Ispecialise -IsimplCore - > Istranal -IstgSyn -IsimplStg -IcodeGen -Imain -Iprofiling -Iparser - > IcprAnalysis -IndpFlatten -Iiface -Icmm -InativeGen -Ighci -I../ > includes -- -O -I/opt/local/include -Iparser -I. -O -- parser/ > cutils.c parser/hschooks.c > /opt/local/bin/perl -pe 'binmode(stdin); binmode(stdout); > s@(\S*[._]o)@stage2/$1@g; s@(\S*[._]hi)@stage2/$1@g; s(a)^.*/compat.* > $@@g;' <.depend-BASE >.depend-2 > /usr/bin/make -C compiler stage=2 > ../compiler/stage1/ghc-inplace -cpp stage2/ghc-inplace.c -o stage2/ > ghc-inplace > ld: in /Users/gwright/Desktop/ghc-6.8.2/libraries/haskell98/dist/build/ > libHShaskell98-1.0.1.0.a, archive has no table of contents > collect2: ld returned 1 exit status > make[2]: *** [stage2/ghc-inplace] Error 1 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 Again, this is running from a Makefile, not from Cabal directly. > In this last case, it looks as if libHShaskell98-1.0.1.0.a is being > used before ranlib has been run on it. The interesting thing is why this happens in your environment and not more generally. Admittedly, looking at the Makefile that cabal generates it does not mention ranlib but then if that were the problem we would expect all builds on OSX to fail always, which is clearly not the case. So again, I don't know what's going on :-) > The common theme of these errors is that they all come out of Cabal, Actually all of these are Makefiles, though possibly Makefiles generated by Cabal. > and seem to involve using the results of external processes before > they are ready. In the original case of the temporary file used to > record the version number, runProcess/waitForProcess are used. In the > last case (running ranlib), runProcessPosix/waitForProcess are used. runProcessPosix? > Since the bug seems to be a race condition, it's not surprising that > changing the code can cause it to disappear for a while. I will > continue to look at what runProcess and waitForProcess are doing. Do > you know of anything in Cabal that might confuse the handling of > external processes? No. It uses rawSystem for most purposes which waits for process termination or for the rawSystemStdout it uses runProcess and waitForProcess. However, as I said, the above examples were from Makefiles not from code in Cabal. > Were the original reports of weirdness in detecting the version number > on OS X, or another operating system? They were OS independent, it was just due to using a dir that was not writable rather than the proper tmp directory. It was not related to locking. The only other similar bug I've seen was on Windows where cabal-install sometimes fails to delete a file in a build directory due to it being locked, even though the last process to use that file has terminated. So all in all, I'm confused. Duncan

1 0

Re: [Hackage] #34: specify a way to add .o files to a library
by Hackage 28 Dec '07

28 Dec '07

#34: specify a way to add .o files to a library ----------------------------+----------------------------------------------- Reporter: igloo | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Comment (by guest): By a build hook, probably. Possibly by another hook, or outside of Cabal completely. All you have to do is to tell the linker to link them, though. Ian -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/34#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Passing arguments through to configure
by Bryan O'Sullivan 28 Dec '07

28 Dec '07

I'm writing bindings for LLVM at the moment, and I'm using autoconf to ensure that LLVM is really installed, and that the necessary version is present. Unfortunately, I can't find any pre-existing examples of how to pass arguments from Setup configure through to configure. This is something I need so that I can build against an SVN build of LLVM, instead of installing it to /usr/local where it would indeed get found. What I'd like to be able to do is augment the arguments accepted by Setup configure to include e.g. --with-llvm=/PREFIX and then pass that through to ./configure. After reading the Cabal source for a while, I eventually noticed --configure-option, but I was hoping to do something a little more integrated, along the lines of adding a --with-llvm option. Is this realistic? The code doesn't currently seem to be set up to permit that kind of extensibility. <b

2 1

patch applied (cabal): Use os(windows) not os(win32) in user guide configurations example
by Duncan Coutts 28 Dec '07

28 Dec '07

Fri Dec 28 04:57:35 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Use os(windows) not os(win32) in user guide configurations example Spotted by Spencer Janssen M ./doc/Cabal.xml -2 +2

1 0

patch applied (cabal): Use getTemporaryDirectory from Distribution.Compat.Direcotry
by Duncan Coutts 28 Dec '07

28 Dec '07

Fri Dec 28 04:55:30 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Use getTemporaryDirectory from Distribution.Compat.Direcotry for compatability with ghc-6.2.2 M ./Distribution/Simple/Utils.hs -2 +1

1 0