On Fri, Dec 8, 2023 at 7:38 PM Paul Smith <psm...@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