Are you guys also reading this line as the relevant argument applying to my case:
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/make.html 'Include lines and rules for creating dynamic include files do not depend [directly or indirectly] on the contents of any earlier dynamic include file.' My case is: two include files, both dynamic with targets and recipes (targets A and B), a third non-include file (target C). A is producing the recipe for C, and B has C as prerequisite. (Sorry for quoting POSIX on a GNU list.) On Friday, June 20th, 2025 at 5:13 PM, Philip Guenther <guent...@gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Philip Guenther <guent...@gmail.com> > Date: Thursday, June 19, 2025 > Subject: Re-executing..., when and when not? > To: WaitronCharm <waitronch...@proton.me> > > > On Thu, Jun 19, 2025 at 2:31 PM WaitronCharm <waitronch...@proton.me> wrote: > > > > Thank you. Yes exactly that happens: 't4' is re-made in the 1st execution > > based on a -- by now -- outdated recipe. > > > > And why 'make' does not wait with that for the 2nd execution? > > > > I guess because 't9' is also included and 't9' has 't4' as prerequisite. > > It does that because that's how it's defined to behave ("After *all* > makefiles have been checked, if any have actually been changed, `make' > starts with a clean slate and reads all the makefiles over again.", > emphasis mine) > > It's a more efficient process to build everything you can in one go, > enabling parallel builds to be more effective. > > > > Now I need to scratch my head how to resolve this (so far I believed > > correct) > > IMHO the recipe for rebuilding t4 is not correct because it does not > reflect that it must be run from a make process that has the current > version of t2. Using a recursive make call fixes the recipe to not > have that implicit dependency. > > > Philip Guenther
