Why are some pre and post phases not enabled by default?

The default package build phases are

$prePhases unpackPhase patchPhase $preConfigurePhases configurePhase $preBuildPhases buildPhase checkPhase $preInstallPhases installPhase fixupPhase installCheckPhase $preDistPhases distPhase $postPhases

But builds also commonly include phases like postInstall, preFixup, postFixup and so on.
These are often activated manually by running runHook preInstall or similar before and after the corresponding phase.

One common problem I run into is that I want to modify one of those phases when overriding a package, but I do not know if it is being called or not.

Why are these called that way and not activated by default?
Why are they usually called manually using runHook instead of adding them to the phases array?

4 Likes

All proper expressions based on stdenv should explicitly run hooks when their phases are overriden. The hooks need to be run explicitly because the stdenvʼs generic builder runs the pre and post-phase hooks in the default definitions of phases so when the phases are replaced, there would be nothing running the hooks.

It is not ideal but changing it now would break backwards compatibility.

I am almost certain that we had an issue for this on GitHub but cannot find it now.

2 Likes

Never seen your hammering repo. Awesome.

1 Like

It is not ideal but changing it now would break backwards compatibility.

Couldn’t runHook skip multiple runs of a hook, if stdenv called the hook and then a derivation’s phase override repeated the hook? As long as no derivations depend on hooks running multiple times, or being able to skip a hook, but that seems like bad behaviour on the part of the derivation.

1 Like