Stack doesn't seem to handle projects with custom Setup.hs or submodules well?

[pharaun]

I am not for certain if this is a stack issue or a project issue thus I went ahead and filed the ticket on the project, but I'm linking it here as well: jakubfijalkowski/hlibsass#2

But basically the project has a custom Setup.hs and then it doesn't pack up the cbits directly into the repo, it submodules it. So I'm not sure if the fact that stack seems to be able to "build" the project the first time fine, but then henceforth fail to link to it the 2nd onward time is stack's problem or if its the build script problem.

I was able to workaround this issue by making the project a submodule of my main project and forcing the libsass submodule in the project to be also cloned, then henceforth all builds worked.

[jakubfijalkowski]

I did a little bit of investigation on this (I'm the author of hlibsass) and this seems to be related to the way stack installs dependencies.

libsass is written in C++ and thus it is quite tricky to force GHC to compile it as c-sources. That's why hlibsass bundles libsass(extra-source-files) along with Makefile and invokes make when configuring the library. This all works both with cabal-install and with stack.

The problem is - cabal-install invokes a postCopy hook for every dependency. hlibsass uses it to copy the generated library (libsass.a) to the installation directory so that projects that depend on it may link to it easily (installation dir is already on the linker search path). stack does not invoke a postCopy nor a postInst and hence setup cannot copy the library. This in turn makes builds to fail.

The first build (and by the first I mean the first one after hlibsass is installed for the first time in the pkg database) works simply because hlibsass is being built in a tmp directory and it gets purged after a build process finishes so libsass.a is still available.

I don't know how to overcome this - postCopy and postInst hooks are in my opinion best suited for this kind of work, but they are of no use here. I could make this happen in a preConf or postConf but I don't know how to get a correct output path (configDistPref/absoluteInstallDirs/other?).

[snoyberg]

I have a feeling this is an idiosyncrasy in the Cabal library. We call out to the runghc Setup.hs install command, which presumably should call a postCopy or postInst hook. We could instead try calling runghc Setup.hs copy and runghc Setup.hs register, which may work around this bug. I'll push a commit to do that now.

[snoyberg]

Could you try out the latest master (stack upgrade --git)?

[jakubfijalkowski]

Yeah, give me a sec.

[jakubfijalkowski]

Seems to work fine now. Thanks!

[snoyberg]

Thanks for confirming, closing. This is a bug that should ideally be opened up with Cabal (runghc Setup.hs install does not trigger install hooks).