Specify components when configuring, not building

[snoyberg]

I'd like to share an idea and get feedback as to whether such a change would be accepted in Cabal. Currently, selection of which components to build is done as part of the build step. I know of at least three issues with this:

• Dependencies for components we don't want to build must still be present. Consider a .cabal file with 2 executables: A has very few dependencies, and B has many dependencies. In order to build executable A, we have to provide all of the dependencies for B. (Related: dependencies are checked even if buildable is False #1725)
• Suppose a package has a library and two executables. If you build the library and one executable and then run the copy command, it will fail since the second executable is not present (see: copy command fails when building only some components #2780)
• If an executable relies on a library in the cabal file, there's no way to say "use the already installed version of the library, and don't rebuild the library here." This can be useful for avoiding unnecessary recompilation, especially in the presence of changing cabal_macros.h files (see: Disable library building, only build other components #2775)

My proposal: add a new command line option to the configure command, which will take a command-separated list of components to include, ignoring all other components. E.g.:

runghc Setup.hs configure --components=lib,exe:foo,test:bar,bench:baz

The semantics would be: all further commands run will implicitly filter out all non-listed components from the .cabal file.

An alternative- and possibly simpler- implementation that would be a bit hairier but still probably work would be providing a --cabal-file argument that would force Cabal to read from a given .cabal file. Then we could create temporary .cabal files with the necessary components stripped out.

Can someone comment on whether such a patch would be accepted, and give any insight into best approach to implementing if so?

[23Skidoo]

This seems reasonable to me, and we already do this for benchmarks and test suites. Default behaviour could be the same as it is now.

/cc @dcoutts

[snoyberg]

@23Skidoo Just to confirm: do we need to wait for @dcoutts to sign off on this proposal, or is this an acceptable idea to start implementing?

[23Skidoo]

Duncan seems to be busy right now.

I think it's fine to start implementing as long as the patch is backwards-compatible, i.e. cabal configure; cabal build exe:foo still works as before (but cabal configure --components=lib; cabal build exe:foo fails like it now does for disabled test suites).

[snoyberg]

Cool, sounds like a reasonable requirement for the new feature.

[phadej]

Could the first stage be to provide --enable-library, --enable-executables and disable counterparts to be consistent with existing --enable-tests and --enable-benchmarks?

One immediate feature would be to be able to run tests against installed library, with

cabal configure --disable-library --enable-tests
cabal test

when test suite depends on the library and not hs-source-dirs: test src.

Either this first stage, or original issue could be doable task for this week hackathon?

[ezyang]

@dcoutts hasn't responded here, but based on communication with him at last ICFP, my understanding is that Duncan is keen to resolve issues 1 and 2 differently, by having Cabal continue to configure all components by default, but making it non-fatal if some components cannot be configured. (And then fixing copy to not attempt to copy components which failed configuration.)

This doesn't fix 3, but maybe you just need a different flag to override internal dependencies.

[ezyang]

(I guess I should add, my natural inclination is to do everything per component.)

[ezyang]

@phadej You are right. In fact, this should be very straightforward to implement. Here's how to do it:

1. Add exeEnabled and libraryEnabled fields to Executable and Library data types in Distribution.PackageDescription, and then update allBuildInfo and other use sites of testEnabled and benchmarkEnabled to respect these new fields.
2. Update configureFinalizedPackage in Distribution.Simple.Configure to also update libraries/executables based on the new flag you introduce. For simple flags like --enable-executables it will look exactly just like the current code; if you want to implement --component you'll have to look more closely at the name of the component.

Willing to advise someone who want so to do this.

[ezyang]

CC @mgsloan. I just realized that my patchset doesn't solve this feature request in its entirety, because it only supports configuring a single component at a time, rather than multiple components. I suppose it would not be too difficult to extend the patchset to also support multiple components, but if you can configure one component at a time, is it still necessary?

By the way, --cabal-file was implemented in #3553.

[dcoutts]

For our general sanity I suggest we stick with one. This isn't useful as a human interface anyway, only as a machine for tools.