design of SUBST_STAGE=post-install behavior?

[brook%biology.nmsu.edu@localhost (Brook Milligan)]

I am unclear on the intended design of the substitution mechanism when
invoked at the post-install stage.  Specifically, is it intended that
this substitution mechanism may be used to modify files within
$PREFIX?  (Why else would substitutions be done, for example, at the
post-install stage?)  Further, is it intended that a sequence such as
'make install; make deinstall; make install' should have the same
effect as 'make install'?

These questions are prompted by a use case in which I need to
substitute in installed files during the post-install stage and have
noticed that the command sequence 'make install; make deinstall; make
install' does not perform the substitution for the second install.

As currently implemented, mk/subst.mk creates cookie files of the form
.subst_${_class_}_done, which are only deleted when the work directory
is deleted.  Thus, after a 'make install' command that performs a
post-install substitution a cookie file will be created.  A subsequent
'make deinstall' does not delete that cookie file.  Consequently, a
second 'make install' will not run the intended substitution commands.
As a result, the installed files are different than those installed
the first time.

So, what is the intended design here?  Is this behavior indeed what is
desired?  Should substitutions at the post-install stage be handled
specially, perhaps by not creating a cookie file?

Thanks for a clarification.

Cheers,
Brook