"Cabal ignores ld-options?" - 2011 remix

[Duncan Coutts]

On Mon, 2011-01-31 at 01:13 -0500, Ryan Newton wrote:
> Ok, I've made some progress in the direction Duncan suggested.
> 
> I can filter out the extra library before the postConf hook gets it.
> And calling "make" from the hooks is pretty easy.
> 
> I've got a hack working that does allow full build/link/install given
> a hardcoded path (e.g. hack).  It works by passing -Wl,-rpath=/opt/...
> directly through the .cabal file (ld-options).  I need to un-hardcode
> that directory but I can't figure out how to achieve the same effect
> as that ld-options from my Setup.hs (I tried adding buildProgramArgs
> in the buildHook but no luck yet).

Just modify the package description instead, e.g. in the configure step.
The build prog args is intended for users, not for package authors. 

(It's so that cabal build --$PROG-options= works, and that's not
something you're supposed to interfere with. Afterall, users are in
control and can always add whatever options they want by adding wrapper
scripts etc, this just makes it more convenient.)

> There's also the question of how to find the install dir so that rpath
> can be set to it.  Unfortunately, I haven't been able to dig that out
> yet.  When I try to use absoluteInstallDirs via something like below,
> I get this error: "setup: internal error InstallDirs.libsubdir"
> 
>   putStrLn$ "Install dirs: " ++ show (absoluteInstallDirs desc linfo
> NoCopyDest)

You're doing the right thing, just don't look at the libsubdir or
datasubdir after calling absoluteInstallDirs, because those do not make
sense after making the paths absolute (they're inherently relative).

The reason it's labelled as an internal error is because if cabal were
ever to call those, then it would be an internal error. When you call it
however, it's your fault ;-)

Duncan