Change in behaviour in HEAD w.r.t copying and installation of executables in packages with Custom setups

[sheaf]

Commit f70fc980dca50e7e62c5e803f56d2ef0c9fc7e18 appears to have changed the behaviour of the installation of executables in packages with Custom setups.

It seems that, when building a package pkg that depends on the library component of the dep package which also contains an executable, we no longer build and install the executable. On the face of it this seems sensible – after all, if we depend on the library, why should we also build the executable? – but it can break workflows, for instance if dep has a custom Setup script which runs the executable (such is the case for Agda).

A reproducer is to depend on a local tarball package with Custom build type and whose copy hook runs the executable.

[alt-romes]

Indeed, as Sam noted we are no longer building executables if they are not a target/argument to build or install.

The description of e8c9d19487cce31bbe8700b971c29db0af1131b7 may also shed some light on this.

For example, if we have pkg-a.cabal:

library
   build-depends: pkg-b

and pkg-b.cabal:

library
    exposed-modules: ...

executable pkg-b-exe
   main-is: ...

An invocation with cabal build pkg-a will build lib:pkg-a and lib:pkg-b, but not exe:pkg-b-exe (because it is not needed for building pkg-a! I think this is a good improvement on one hand).

If the invocation were cabal build pkg-a exe:pkg-b-exe then all lib:pkg-a, lib:pkg-b, and exe:pkg-b-exe would be built.

I'm not sure how to better handle the fact that some Custom setups may depend on an executable being built as well regardless of the target, but we should fix this as it breaks at least Agda's workflow.

[mpickering]

In any case a refactoring shouldn't also change behaviour. So perhaps we can restore the old behaviour and then make a more informed/slow decision about what should happen.