`build-type: Hooks`: Lift restriction regarding per-component builds

[mmhat]

I'd like to use build-type: Hooks in a package that has internal sublibraries.
Since packages containing internal sublibraries force a per-component build thaty is currently not possible:

Error:
    Internal libraries only supported with per-component builds.
    Per-component builds were disabled because build-type is Hooks
    In the inplace package 'thrift-lib-0.1.0.1'

More specifically, building thrift-lib requires the compilation of some Thrift interface files to Haskell modules;
See https://github.com/facebookincubator/hsthrift/blob/e84c886276f39f6c55389c1f1bf96f90fe76f49e/Makefile#L29 for how it is currently done. As this compilation can be done per component, I wanted to add per-component hooks for the generation of the Haskell sources.
If a SetupHook files specifies only per-component hooks, then it should be safe to allow this in a per-component build, shouldn't it?

Related issue: #4548 #10966

[mpickering]

This is related to #10966

I think the right way to fix this is in the short term to allow packages with multiple sub-libraries to be built in the per-package way, I looked briefly into it and it didn't appear to hard to do. Cabal can already produce multiple .conf files, but cabal-install needed to be modified to account for the possibility of a build producing multiple .conf files.

[mmhat]

This is related to #10966

@mpickering Oh, thanks; Yes, I meant this one!

I think the right way to fix this is in the short term to allow packages with multiple sub-libraries to be built in the per-package way, I looked briefly into it and it didn't appear to hard to do. Cabal can already produce multiple .conf files, but cabal-install needed to be modified to account for the possibility of a build producing multiple .conf files.

Hm, I wonder what would be the long term fix? After digging into this issue myself a bit maybe something like the following:

1. Adjust Distribution.Simple.defaultMain and friends such that we can query if we can do a per-component build or not, i.e. something like a new command has-capability <STRING> that gives us information about the things this setup can or cannot do.

   For this issue it would probably be sufficient if that change was only made to Distribution.Simple.defaultMainWithSetupHooks{,Args}, but it may be simpler if all entrypoints consuming UserHooks could respond to such a query.

2. During preparation, query the (updated) Setup.hs like runhaskell Setup has-capability per-component-build. Then, depending on the exit code and the output of that command, we either proceed with the per-component build (if it is supported by the particular setup method), we fall back to the current behaviour (for example, if the implementation in Setup.hs does not understand the has-capability subcommand), or we throw another error (if the setup program exits with 0, but the output is unexpected).

Note that the above is more an idea than a proposed way forward; I am still trying to understand what our options are. Also, I am aware that there are other means of setting up a project, but I have not yet looked into those.

[mpickering]

In #9871 cabal-install is able to call the hooks executable directly to learn about additional configuration (rather than go through the whole ./Setup interface). Once that patch is finished (I'm told it's nearly there), then it should be possible to remove the restriction that Hooks implies whole-package builds. Let me know if you want me to explain #9871 some more or the idea behind it.