cabal ignores ld-options?

[Duncan Coutts]

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