Coping with weirdo third party packages

[Duncan Coutts]

On Thu, 2007-12-27 at 23:26 -0800, Bryan O'Sullivan wrote:
> 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.

Usually you would use "ld-options:" but in this case that will not help
you since your flag really is for ghc. I'm not sure what you want to do
is currently possible, except perhaps by passing --ghc-option=-pgmlg++
at configure time, but that's not very convenient.

> 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`

ld-options should help here, and you could use Setup.hs to call
llvm-config.

> 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.

In that case try just hard-coding the ld-options rather than using
Setup.hs to call llvm-config.

> 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.

extra-libraries really is for libraries, it's fairly easy to convert -l
flags and similar into the right stuff. Cabal provides a function to do
so (though only available in Cabal-1.3.x):
ccLdOptionsBuildInfo :: [String] -> [String] -> BuildInfo
ccLdOptionsBuildInfo ccflags ldflags = ...

it looks for -I, -l, -L flags and puts them in the appropriate sections.
Other flags end up in cc-options or ld-options.

> Cabaliers, would you like some patches for 2 and 3 above?  What should
> we do about 1?

See if using ld-options fixes 2 and 3.

I'm not sure about 1 either. It's part of the more general problem of
developing multi-language stuff using C++. What do other people do when
using a mixture of compilers, each of which wants to be used for the
final link?

Duncan