"Cabal ignores ld-options?" - 2011 remix

[Ryan Newton]

Victory!  Thanks!

Well.. mostly victory ;-).  I've got it in a state where the .cabal
file rewriting works if "cabal configure" is called separately from
"cabal build/install" so that the latter reads the modified
configuration file.  Right now I'm patching the .cabal file from the
postConf flag... maybe I could fix this problem by doing the patch
from preConf instead (presumably confHook reads the file?).  But
there's a bit of a chicken-and-egg problem because I use
LocalBuildInfo to find libdir and that is computed by the configure
action!

I'd be really curious if anyone else can compile this ;-).  It's not
on hackage yet but you can get it with"git clone
git://github.com/rrnewton/intel-aes.git".

As for portability...  I'm afraid I don't personally do any
development on Windows.  Presumably the goal is for hackage packages
to work without requiring Cygwin/make/etc?

Does anyone have a GHC7 setup in windows who would be interested in
helping a bit?  The C/asm code that I'm wrapping does have a .bat file
that is supposed to build it.  It might be easier if yasm.exe is
included in the package (it was in the original
Intel_AESNI_Sample_Library_v1.0.zip).

Thanks,
  -Ryan



On Mon, Jan 31, 2011 at 6:43 AM, Duncan Coutts
<duncan.coutts at googlemail.com> wrote:
> 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
>
>