Cabal: copy command fails when building only some components

[snoyberg]

Actions:

1. Create a project with both a library and executable
2. cabal clean
3. cabal configure
4. cabal build lib:packagename
5. cabal copy

Expected: command succeeds, copying over the library only, and not the test suite

Actual: errors out since the executable does not exist, e.g.:

Installing library in
/home/vagrant/.cabal/lib/x86_64-linux-ghc-7.10.2/tmp-0.1.0.0-JdaAODhQa7p5WhxMngbYYt
Installing executable(s) in /home/vagrant/.cabal/bin
Setup.hs: dist/build/tmp-exe/tmp-exe: does not exist

This problem could be mitigated by allowing copy to take a list of components like build does.

[lukehoersten]

+1

[mgsloan]

Recently ran into this one... +1

[mgsloan]

@ezyang Did this not make it into Cabal-1.24? If so, why not? The change was made quite a while before release We have a long lived P1 about this in stack https://github.com/commercialhaskell/stack/issues/1406

Also, looking at the code, it looks like this deviates from the component syntax used by configure. Why do that?

Also, why not just copy whatever was last configured?

[ezyang]

I don't think there was any good reason it didn't make it into 1.24, except that the commit landed after 1.24 branched, wasn't milestoned for 1.24, and so never got merged back into the 1.24 branch. IIRC there is going to be a GHC 8.0 point release? Then we ought to merge it in for then.

Also, looking at the code, it looks like this deviates from the component syntax used by configure. Why do that?

I don't know what you are referring to. I don't think you referring to --enable-tests / --enable-benchmarks in configure... are you referring to ./Setup configure cname? That functionality is still in a PR and not merged to HEAD. (See https://github.com/haskell/cabal/pull/3662) But if you are referring to this, the syntax IS the same, but the entry point is a bit different because at configure time we don't have a LocalBuildInfo, and I refactored the build/register/etc code to work with a LocalBuildInfo because that was more convenient.

So, just to recap, in the per-component configure branch, we use readBuildTargets to parse arguments, In all other cases, we use readTargetInfos, which itself uses readBuildTargets to parse arguments (it then consequently resolves it into a ComponentLocalBuildInfo from the LocalBuildInfo).

Also, why not just copy whatever was last configured?

You seem to be assuming that there is a way to configure a set of packages to install in 1.24! Did you mean to copy whatever what was last _built_? I suppose that is possible, but this would imply ./Setup build somehow saves the set of arguments it was called with, which copy then takes. Isn't just specifying it explicitly better?

Sorry, maybe I am massively misunderstanding the question.

[23Skidoo]

Backporting this to 1.24 looks non-trivial, so I'm inclined to leave it be.

[mgsloan]

@ezyang Ahh, I didn't realize that exe-name was a valid cabal build target. Thanks!

You seem to be assuming that there is a way to configure a set of packages to install in 1.24! Did you mean to copy whatever what was last built? I suppose that is possible, but this would imply ./Setup build somehow saves the set of arguments it was called with, which copy then takes. Isn't just specifying it explicitly better?

Sorry, maybe I am massively misunderstanding the question.

True, I meant the build step. Yeah, explicit is probably better for the Cabal layer.

Backporting this to 1.24 looks non-trivial, so I'm inclined to leave it be.

Would you be inclined to merge if I implemented a new fix atop 1.24? The alternative is going to be to move more and more Cabal functionality into stack / Setup.hs hacks.

[ezyang]

Surely it can't be that hard to backport. The main thing is I refactored Install to operate on a per-CLBI basis prior to this patch; you'd have to also bring in those changes as well.

[23Skidoo]

Looking at #3022 (which is the version that got merged), I see that the patch in question (f88f502d85b60b7ca5993fdccfa069d7b313e174 ) is number 25 in a series that includes 2040c1c937956f7bbb9be61e2a655211a862db38 among other things. This makes me somewhat uncomfortable with the amount of changes required in the supposedly stable branch.

@mgsloan

Would you be inclined to merge if I implemented a new fix atop 1.24?

Sure, if you or @ezyang are willing to do the actual work, I'll reconsider.

[23Skidoo]

@mgsloan

So people are asking for a new 1.24 release, should I wait for your patch or remilestone this ticket for Cabal 1.24.0.2?

[mgsloan]

Feel free to make the release. I'll take a look and may have a patch ready soon

[23Skidoo]

@mgsloan Thanks!

[ezyang]

@mgsloan GHC 8.0.2 is coming soon, so this is your last chance to get a 1.24 patch in!

[23Skidoo]

@mgsloan @ezyang Guys, is this still broken or is the ticket only open because the fix is not in 1.24? If it's the latter, I think we should close it.

[snoyberg]

The problem still exists with Cabal 2.0:

$ stack --resolver ghc-8.2.1 exec --no-ghc-package-path -- runghc Setup.hs configure --user
Configuring foo-0.1.0.0...
$ stack --resolver ghc-8.2.1 exec --no-ghc-package-path -- runghc Setup.hs build lib:foo
Preprocessing library for foo-0.1.0.0..
Building library for foo-0.1.0.0..
[1 of 1] Compiling Lib              ( src/Lib.hs, dist/build/Lib.o )
$ stack --resolver ghc-8.2.1 exec --no-ghc-package-path -- runghc Setup.hs copy
Installing library in /Users/michael/.cabal/lib/x86_64-osx-ghc-8.2.1/foo-0.1.0.0-wI4nsLkf3p3YT1pJBa9gp
Installing executable foo-exe in /Users/michael/.cabal/bin
Warning: The directory /Users/michael/.cabal/bin is not in the system search
path.
dist/build/foo-exe/foo-exe: copyFile: does not exist (No such file or directory)

I understand that Cabal 2.0 has introduced per-component configuration, which is intended as a workaround. I've discussed with @ezyang, and the ultimate plan is to add support for this to Stack (which will be necessary for Backpack anyway). In the meanwhile, we have a workaround in Stack that forces the executable component to be built the first time.

So my take: I still consider this a bug that is unfixed in Cabal 2.0, but we're effectively working around it in Stack.

[23Skidoo]

@snoyberg Thanks!

[ezyang]

Sorry I missed the conversation here. Let me clarify a few points:

• Per-component build will solve the problem, as @snoyberg says
• ./Setup build someexe && ./Setup copy indeed does not work in Cabal HEAD (and it will never work, for reasons explicated earlier in this ticket; specifically, Cabal would need to start tracking state of "what the most recent set of executables that were built" where, and this just doesn't seem like a good answer when there's a better solution below)
• ./Setup build someexe && ./Setup copy someexe (@snoyberg suggested alleviation at the very beginning of this ticket) works in Cabal 2.0, and it may be worth adding the little bit of logic to support it