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