Hi Paul,

On 7/22/22 16:20, Paul Smith wrote:
On Fri, 2022-07-22 at 14:05 +0200, Alejandro Colomar wrote:
As the word suggests, as pre-requisites are satisfied before a given
target, post-requisites would be satisfied _after_ a given target.

The way I can see this being implemented without a very significant
amount of work, would be for make to dynamically add goal targets based
on some internal syntax such as you describe (I'm not sure I like the
">" token however... needs thought).

I chose '>' because it doesn't seem to be in use by GNU make. Also, there's no $> automatic variable yet in GNU make (I ignore other make(1) implementations), which could be added to contain the post-requisites of a given target

So, after all the "normal" goal targets were completed make would
proceed to run any "extra" goal targets that were added as part of the
processing of the "normal" goal targets.  Then after the those "extra"
goal targets were complete, make would proceed to run any "new extra"
goal targets that were added as part of THAT processing.  Etc.

Since of course we never build the same target twice in a single
instance of make, this cannot result in an infinite loop.

However this would need a more detailed specification.  For example
does a "post-requisite" get built only if its target is considered out
of date and its recipe invoked?  Or does it get built if the target is
considered, regardless of whether it's up-to-date?

Also, is it up to make to FORCE the post-requisite to be built, if its
target was built?  Or is it only rebuilt if it's considered out of date
in its own right as a normal target?

I'd say that post-requisites need only be build if they are not up-to-date. Let the user tell make(1) that a post-requisite needs to be build regardless of its up-to-date status by marking it .PHONY or FORCE.



Alejandro Colomar

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to