On Wed, 2020-11-04 at 10:48 +0000, Geoff Clare via austin-group-l at
The Open Group wrote:
> > -----------------------------------------------------------------
> > (0005094) psmith (developer) - 2020-11-03 15:23
> > https://austingroupbugs.net/view.php?id=1325#c5094
> >
> > Regarding the change to page 2891 lines 97033-97035:
>
> It's there because GNU make uses re-execution. The re-executed make
> doesn't know what targets the previous invocation updated, so it
> doesn't know to treat them as already up-to-date.
I understand. I need to stop thinking of the re-exec'd make and simply
consider the entirety of the process. The real process GNU make
undertakes is something like:
1. Read all makefiles. Don't error if they do not exist.
2. Consider all makefiles as goal targets and try to rebuild them.
3. If any rebuild, clear out all knowledge of all parsed makefiles and
go to step 1 (GNU make does this via re-exec but that's not required
of course).
4. If any required makefiles are missing, fail.
5. Build the normal goal targets.
So, it's never the case that by the time you get to step #5, any
makefile will be reconsidered: at that point all makefiles will be
known to be up to date.
> The aim here was to describe the cut-off-point where all include file
> generation has been completed and after which the new contents of the
> files is used. This cut-off-point needs to be before make starts the
> "real work", i.e. starts the work to bring the first target operand,
> or the first target make encounters if there are no operands, up-to-
> date.
Can we just say that? All include file regeneration is complete before
make attempts to bring the first target_name operand, or the first
target make encounters if no target is specified?
> > In the portability text (second bullet), a portable workaround to
> > using a macro defined in one included file in the include line of
> > another, is to put the second include _inside_ the first included
> > file instead of in the outer including makefile.
>
> Okay, that sounds like it is worth adding. Maybe something like:
>
> Include lines and rules for creating dynamic include files do not
> depend on the contents of any earlier dynamic include file. For
> example, defining a macro in a dynamic include file and using
> that
> macro in a later include line should be avoided (unless the later
> include line is itself inside the dynamic include file).
OK.
> If adding "ddir" to the search path is achieved by means of an
> extension (such as -I), then the requirement in the standard does not
> apply to "ddir"; it only applies to the default search path.
>
> It is only the default search path that I see as a problem. If a
> user explicitly wants a directory searched, then that implies they
> know what's in that directory and will choose include file names with
> that in mind. If there's a clash which causes their makefile to
> behave differently than intended, that's the user's fault.
Yes, exactly.
> Sounds like we are in agreement with how GNU make should handle this
> issue. It can prioritise specified search paths over remaking, but
> not the default search path. I believe the currently proposed text
> allows that, because specifying a search path involves using an
> extension.
OK, I'm OK with making this change to GNU make to meet the standard if
needed.
Thanks!
