Re: Bug with $(info xxx) in 4.2.1

[Jouke Witteveen]

On Fri, Dec 8, 2023 at 7:38 PM Paul Smith <psmith@gnu.org> wrote:
>
> In make it's fine to have a make line indented with a TAB, that is not
> part of a recipe.  If a line appears outside of the context of a rule,
> then leading whitespace is ignored.

There is a section in the documentation called "How Makefiles Are
Parsed" which contains:

3. If the line begins with the recipe prefix character and we are in a
rule context, add the line to the current recipe and read the next
line.

Maybe that should be tweaked to indicate that it only applies "in a
recipe context".

> This can be seen by the example given, where the variable assignment
> line did not generate an error.  You can do this simpler experiment
> without the ifeq, which is irrelevant for this issue:
>
>           FOO = bar
>           $(info baz)
>   all:;
>
> (where the first two lines are indented with TAB).  Here you will see
> that make accepts the first line but fails on the second line:
>
>   $ make
>   Makefile:2: *** recipe commences before first target.  Stop.
>
> The reason for this is that make tries to understand what kind of line
> it has, BEFORE it expands the line.  You can tell it is not expanded
> because the info function's output is not shown.  So in the first line,
> make sees that it's a variable assignment and it accepts it.
>
> However make doesn't know what kind of line the second line is, and
> before it expands the content and realizes that the result would be the
> empty string it generates this error.

The documentation continues with:

4. Expand elements of the line which appear in an immediate expansion
context (see How make Reads a Makefile).
5. Scan the line for a separator character, such as ‘:’ or ‘=’, to
determine whether the line is a macro assignment or a rule (see Recipe
Syntax).
6. Internalize the resulting operation and read the next line.

The last statement suggests that a line containing only a variable
reference or macro expansion, such as $(aaa) or $(info xxx) presents
an immediate expansion context, although it does not meet any of the
stated forms of an immediate expansion context as defined in section
"How make Reads a Makefile".

It is not entirely clear to me whether implemented behavior, the
documented behavior, or neither is best. The documentation was updated
a few years ago. Back then, I already observed these inconsistencies
[SV 51974].

Probably these observations are only tangentially related to the issue
at hand, but I thought it would be worth highlighting for some more
context.

> However, this behavior should probably be considered a bug.  Aaron, it
> would be helpful if you could file this as a bug in Savannah:
>
> https://savannah.gnu.org/bugs/?group=make&func=additem

Cheers,
- Jouke