Copying executables when installing is fragile with packages relying on the paths in Cabal's Paths_<pkg-name> module #828
Comments
|
cabal install and stack are doing the same thing here: neither one is recompiling executables. You can see that, for example, by running |
|
Ok so if I do the following with cabal-install: Then The problem is that |
|
What would you suggest the preferred behaviour be? |
|
And perhaps you can describe the problem you're actually trying to solve? I read through the linked issue, and couldn't understand what problem the libexecdir is trying to work around. |
|
Hmm it seems like this issue is more weird than I though. On second look the If I add a plain And now I use a custom Setup.hs to implement the |
|
I'm starting to think the initial bug report was bogus, if I install ghc-mod with stack locally everything just happens to end up in the right path. I still believe the deviation from what cabal-install would do with bindir, libdir etc. is a bug though. How to solve that properly I have no idea. What I would do is 1) make
|
|
I've fixed the libexecdir and sysconfdir not being set, thanks for reporting that. |
|
That's all nice and well but this makes the issue of what happens on |
|
I'm really missing the forest for the trees here, I don't have any idea why this problem exists in the first place. Why isn't cabal-helper just being installed into the bin directory like all other executables? |
|
Alright, reviewing this again, I think I'm starting to understand what you're saying, and where the misunderstanding is starting. For future reference, it would be a lot easier to follow a bug report if it followed the recommended bug reporting guidelines. Current situation: all paths in the The concern that you have is that, when copying an executable from .stack-work/foo/bar to ~/.local/bin, it will still refer to data-files and other such files in .stack-work. This, again, doesn't result in anything being broken. Your concern is that, if in the future the user deletes the .stack-work directory, things will break. Are we still on the same page? And just to round things out: it's not technically true that paths will always be under .stack-work. If the package is part of the snapshot, it will instead be placed inside ~/.stack. Perhaps that's part of the problem you're worried about. I have comments to make about this situation, but I want to confirm that we're actually talking about the same thing. |
|
Alright that makes a lot more sense. I can live with breakage for as long as the package isn't in a snapshot, thanks for the explaination and sorry about the confusion. |
|
No problem. One last thing that might be useful to know: as long as you're building outside a project, the executable ends up under ~/.stack, e.g.: |
|
Ah I was wondering where those were coming from. |
|
What about if you want to install executables that require access to the directories in With then just copy the Is something similar possible with |
|
@pavelkogan: See #848, we're looking to address this. |
Since
stack installis merely an alias for copying executables after building them this means that the Paths_ module doesn't get re-generated for the actual installation prefix but rather remains at pointing to somewhere in.stack-work. This is a real problems for programs or libraries that rely on these paths being correct.cabal installdoes this correctly and rebuilds the whole package with the proper paths in this module.My specific use case is cabal-helper where, in the library, I have to use
libexecdirto find the wrapper executable (since I don't want that to show up on the user's PATH). Since there isn't such a thing as LIBEXECPATH I'm kind of stuck here as I can't think of another way to find my executables in libexec.The text was updated successfully, but these errors were encountered: