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

[sheaf]

Commit f70fc98 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 e8c9d19 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.

[andreasabel]

As pointed out by @sheaf, this behavioral change might have been accidentially released with cabal-install-3.12.1.0.
MWE in this repo: https://github.com/andreasabel/cabal-issue-10235/actions/runs/10163928863/job/28108067382

[Kleidukos]

@mpickering @alt-romes Do you have something to fix this? 3.14 is approaching on the horizon.

[alt-romes]

@Kleidukos I've patched agda in agda/agda#7471 and documented the breaking change in the changelog in #10311. Ultimately, we want to keep the new behaviour, and Agda's workflow can be easily fixed in light of this new, more correct, behaviour. #10311 is ready to merge now.