Add initialBuildSteps removal notice

[ffaf1]

And suggestion on what to use (preBuildComponent) instead.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions). no

[Mikolaj]

Thank you very much.

Could we also mention the PR that removed this? (#9474)

[ffaf1]

Sure and done

[Mikolaj]

CI is dead, but since this is only a documentation fix and an urgent one, unless @sheaf would like to suggest changes, I'd propose to expedite it. If nobody objects, I'd merge manually in a couple of hours.

[sheaf]

I don't think we want to suggest preBuildComponent, because that still does not handle all preparation of sources such as running preprocessors or custom logic. Perhaps we can point to ./Setup repl --repl-multi-file=<fn> instead?

[sheaf]

Thanks for putting up this PR BTW.

[ffaf1]

I don't think we want to suggest preBuildComponent, because that still does not handle all preparation of sources such as running preprocessors or custom logic. Perhaps we can point to ./Setup repl --repl-multi-file= instead?

What would a library user write, instead of initialBuildSteps?

[sheaf]

I don't think we want to suggest preBuildComponent, because that still does not handle all preparation of sources such as running preprocessors or custom logic. Perhaps we can point to ./Setup repl --repl-multi-file= instead?

What would a library user write, instead of initialBuildSteps?

My question is: what is this library user trying to do? I think the only reason one would be calling this function is because one wants Cabal to prepare source files for a package; however, initialBuildSteps only handles things like the paths module and not anything else. I suppose it is OK for a consumer to re-implement all the other logic themselves (running pre-processors, running pre-build hooks, etc), but that seems like duplication of effort that will just lead to more bugs.

So my answer would still be to call ./Setup repl --repl-multi-file, even when using a library interface. Nothing else is correct in the presence of a custom Setup. If one assumes the Setup is not custom, then one can instead directly call repl_setupHooks with the correct pre-build hooks of the package (if there are any).

[ffaf1]

Thanks @sheaf. I added your reasoning (with slight rewording) to the release notes. If you are fine with it, it can get merged.

[Mikolaj]

As advertised here and in the channel, I'm merging before the delay is up and ignoring CI. Thank you all!

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Nothing to do for rebase action

[Mikolaj]

@mergify backport 3.12

[mergify]

backport 3.12

✅ Backports have been created

• #9960 Add initialBuildSteps removal notice (backport #9943) has been created for branch 3.12