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