April 2007 - cabal-devel

Re: cabal ignores ld-options?
by Duncan Coutts 22 Apr '07

22 Apr '07

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

1 0

Re: cabal ignores ld-options?
by Duncan Coutts 22 Apr '07

22 Apr '07

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

1 0

darcs patch: don't automatically include install-incl... (and 2 more)
by Bertram Felgenhauer 20 Apr '07

20 Apr '07

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(a)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(a)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(a)gmx.de> * update documentation for install-headers: field

2 1

darcs patch: add extra-includes field to buildinfo
by Bertram Felgenhauer 19 Apr '07

19 Apr '07

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(a)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.

1 0

Re: building, rebuilding, problems, ALUT,..
by Ian Lynagh 18 Apr '07

18 Apr '07

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

1 0

darcs patch: Stop pretending we might not have any Us... (and 3 more)
by Ian Lynagh 17 Apr '07

17 Apr '07

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(a)earth.li> * Stop pretending we might not have any UserHooks Tue Apr 17 23:50:31 BST 2007 Ian Lynagh <igloo(a)earth.li> * Small tidyup Tue Apr 17 23:56:57 BST 2007 Ian Lynagh <igloo(a)earth.li> * Stop having hooks return an ExitCode that we then ignore Wed Apr 18 00:03:11 BST 2007 Ian Lynagh <igloo(a)earth.li> * Behave the same on Windows and non-Windows

2 1

darcs patch: added cppOptions and c2hsOptions
by Vivian McPhail 17 Apr '07

17 Apr '07

2 1

Problems with "make" after "Setup makefile"
by Bryan O'Sullivan 16 Apr '07

16 Apr '07

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

2 1

[ANNOUNCE] cabal-rpm: build RPM packages from Cabal packages
by Bryan O'Sullivan 14 Apr '07

14 Apr '07

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

1 1

[PATCH] Split SrcDist::sdist into several functions
by Bryan O'Sullivan 14 Apr '07

14 Apr '07

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

1 0