help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: makefile parsing and variable expansion


From: Paul Smith
Subject: Re: makefile parsing and variable expansion
Date: Sat, 03 Oct 2009 16:20:38 -0400

On Sat, 2009-10-03 at 21:09 +0100, Ian Lynagh wrote:
> > Because make's parser is line-based.  Each logical line that is read
> > from the makefile is considered a single line EVEN IF, after expansion,
> > it contains newlines.  A variable statement like this CANNOT expand into
> > a construct that spans multiple logical lines.
> 
> Unless it's indented by a tab, right? e.g.:

Yes; expansion inside of recipes follows a different set of rules,
because make doesn't have to parse those lines (it just hands them off
to the shell to manage).

> Also, this doesn't work:
> 
> inc = inc
> lude = lude
> $(inc)$(lude) wibble.mk

Correct.  "include", "ifdef", etc. are keywords and must appear
verbatim; they are looked for by the parser before variables are
expanded.

> nor this:
> 
> tab = $(nothing)    $(nothing)
> z:
> $(tab)echo foo

Similarly, the initial TAB character is looked for by the parser before
variables are expanded.

Basically the make parser examines the line enough to figure out what
kind of line it is (preprocessor statement, variable assignment, target
definition, recipe statement) before it starts expanding variables,
because different types of lines have different rules for expanding (or
not) variables.  So things like "=", etc. cannot be inside variables;
they have to be explicit in the line.

> > Because make, as above, is line-based.  There's no _normal_ way to
> > introduce a newline into a filename in a prerequisite list.  The only
> > way to do it is via define/endef as you've done.
> 
> Ah, I see. So when foo is expanded the first <newline><tab> turns into
> "some whitespace" at the beginning of the dep list, as does the second
> <tab> inbetween items, but the second <newline> is treated as a
> filename-character.
> 
> But if there aren't any other (non-newline) filename characters
> following the newline, then it looks like it is treated as whitespace
> before the "endef".

I'm not sure of the details here; I'd need to examine how the parser
handles these situations to understand the details.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




reply via email to

[Prev in Thread] Current Thread [Next in Thread]