Coping with weirdo third party packages

[Bryan O'Sullivan]

Duncan Coutts wrote:

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

Yeah.  Alas!

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

It has a weird side effect.  I'm preprocessing some files using hsc2hs,
and Cabal is using ld-options to link the little C program built as an
intermediate product by hsc2hs.  Is this expected?  I'd have thought
that program would be completely standalone, since pretty much all it
does is call printf and fputs.

This causes further problems.  Even if I pass --ghc-option=-pgmlg++ to
"setup configure", it seems to only be used for compilation, not
linking.  I thus have to add -lstdc++ as an ld-option.

The second problem is that preprocessing becomes very slow, since the
LLVM libraries are huge.  It takes longer to preprocess two source files
than to build the entire library.

In order to make progress, I suppose I could either hard-code a
dependency on g++ (aka -lstdc++) or try to figure out the extra
libraries that the C++ runtime needs and add those as ld-options.
Neither way seems especially satisfactory :-(

	<b