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.
Cheers, Alex -- Alejandro Colomar <http://www.alejandro-colomar.es/>
OpenPGP_signature
Description: OpenPGP digital signature
