Use SetupHooks for Configure build-type

[sheaf]

This commit implements the Configure build-type in terms of Hooks, when build-type: Hooks is available (for Cabal >= 3.13).

This moves Configure away from an implementation in terms of UserHooks, i.e. away from the Custom build-type.

---

Template Α: This PR modifies the Cabal API, as it changes the type of the runConfigureScript function and exposes autoconfSetupHooks from Distribution.Simple.

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added.

[alt-romes]

I've added a changelog entry. I've looked through the mentions of configure build-type in the documentation but it is all agnostic to the underlying implementation, so nothing had to be updated. There already exist many tests for the configure build type, so none had to be added either.

This is a great improvement and future proofs build-type: Configure. In fact, when Hooks no longer implies legacy-fallback, neither will Configure!

[andreabedini]

Great work. How sure are we that existing Configure type builds will keep working as before?

[alt-romes]

Great work. How sure are we that existing Configure type builds will keep working as before?

As long as the existing testsuite can observe configure build type for working, the new implementation is working in that it also works for the same testsuite. I’m not entirely sure if you can test divergence between the two (e.g. by comparing a substitution file or environment variables or something) since we didn’t keep the old implementation.

[sheaf]

Great work. How sure are we that existing Configure type builds will keep working as before?

I've built stackage with a patch that contains these changes and it has successfully built all packages (including e.g. time, process etc).

[andreabedini]

I've built stackage with a patch that contains these changes and it has successfully built all packages (including e.g. time, process etc).

Great 👌 I wasn't entirely sure we could have expected any change in semantic.

[alt-romes]

@andreabedini would you like to officially approve this?

[andreabedini]

Looks good. Let me summarise:

• we leave autoconfUserHooks as it is
• we introduce autoconfSetupHooks to expose the same logic (in runConfigureScript) with the new API.
• cabal-install will prefer autoconfSetupHooks when it is available.

Do I have this right?

💯 👍

[sheaf]

Looks good. Let me summarise:

* we leave `autoconfUserHooks` as it is

* we introduce `autoconfSetupHooks` to expose the same logic (in `runConfigureScript`) with the new API.

* cabal-install will prefer `autoconfSetupHooks` when it is available.

Do I have this right?

💯 👍

Yes. I suppose we could also remove autoconfUserHooks. The logic about which one to use is in cabal-install, and that will use whichever one is available in the Cabal library we are using.

[andreabedini]

Yes. I suppose we could also remove autoconfUserHooks.

For the sake of not breaking too many things, I would suggest leaving it. That you were able to implement both APIs on top of the same core logic suggests it's not going to be burden.