SetupWrapper: separate determining and running Setup

[ttuegel]

It is useful to know outside of setupWrapper which Setup version will
be used, so the two phases (knowing and running) are separated.

This is merely refactoring. I need it for my reconfigure branch and I don't want it to get merge-conflicted again while I finish that feature.

[mention-bot]

@ttuegel, thanks for your PR! By analyzing the annotation information on this pull request, we identified @23Skidoo, @dcoutts and @tibbe to be potential reviewers

[ezyang]

So, if I understand correctly, the refactor introduces two new types Setup and SetupMethod which capture the intermediate result of determining what Setup will be used, but otherwise keeps the logic the same? If so, sounds good to me; but let's document the new types. (The commit is a bit fuzzy so it was hard to follow.)

[ttuegel]

Yeah, I still have to fix some merge conflicts that I resolved incorrectly.

Is it a known bug that test output doesn't show up in AppVeyor?

[ezyang]

No; I've never seen the test suite do that log before.

[23Skidoo]

Refactoring SetupWrapper is a good idea in general.

[dcoutts]

@ttuegel I've not looked at the code yet, but I support the principle. Is there any chance that having separated out the working of which Cabal CLI/API version the Setup supports from calling it, that it becomes possible to skip the first step entirely if we know in advance what version will be used? I ask because the "new-build" code path does know up front what Cabal CLI version will be used and this could help simplify things a bit.

[grayjay]

@ttuegel I've not looked at the code yet, but I support the principle. Is there any chance that having separated out the working of which Cabal CLI/API version the Setup supports from calling it, that it becomes possible to skip the first step entirely if we know in advance what version will be used? I ask because the "new-build" code path does know up front what Cabal CLI version will be used and this could help simplify things a bit.

#3723 is related.

[ttuegel]

I've not looked at the code yet, but I support the principle. Is there any chance that having separated out the working of which Cabal CLI/API version the Setup supports from calling it, that it becomes possible to skip the first step entirely if we know in advance what version will be used? I ask because the "new-build" code path does know up front what Cabal CLI version will be used and this could help simplify things a bit.

If we know what Cabal version is being used and we know if we need an external, internal, or self-exec method, then we can simply construct a Setup with the correct values and skip the first step.