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.cou...@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 > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe