> > > the value in the definition of a recursively > > expanded variable is considered to be a "construct", therefore it can > > also be regarded as a "deferred construct"? > > Yes. I think it's useful to consider: > > nam = exp > > ... as a construct of at least two sections, because nam is immediately > evaluated, while the evaluation of exp is deferred.
As in my original question, I agree that the documentation implies that constructs contain sections, some of which are immediately expanded, while others have a deferred expansion. However I do not think the documentation intends for these sections to be also regarded as "constructs" (I believe the term "constructs" refers only to the top-level components of a makefile: rules, variable definitions, directives and comments). > > how can that value "appear in an immediate context"? > > It can't: that was my point in the last sentence of my previous post. Given: > > nam = exp > > It's when $(nam) appears in an immediate context that exp gets evaluated. > exp needn't itself appear again. But if one considers the value in a recursively expanded variable to be a "deferred construct", this type of "deferred construct" cannot "appear in an immediate context", as you said, therefore the wording from the manual: "Expansion of a deferred construct is not performed until either the construct appears later in an immediate context" is wrong, as there are no "deferred constructs" that can appear in an immediate context. However, if the documentation intended for a recursively expanded variable (the variable as an entity, not some part of the parse tree) to be considered a "deferred construct", then this "deferred construct" can appear in an immediate context (it can be referenced, and its expansion would mean the expansion of the value specified in its definition). However, this meaning of "construct" does not match the meaning of "construct" used in the previous sentences. Either way the term "deferred construct" is interpreted, I still believe that this paragraph is not clear or consistent with regards to terminology. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
