handling of spaces in variables and dependencies

[Basile Starynkevitch]

Hello,

I am a ninja newbie (using it only on Linux; I don't know and don't care about Windows and never used it; I am using Unix-like systems since 1987). I have the feeling that there is an important difference regarding space handling in ninja w.r.t. e.g. GNU make.

In make, if I define some global variables:

GLOBVAR= foo.c header.h

and have a dependency

foo.o: $(GLOBVAR)

then the target foo.o depends on both files foo.c and header.h and of course make don't try to look (or stat)  for some hypothetical single file (with a space inside its path) named foo.c header.h with a space inside it.

My understanding is that ninja behaves differently. It seems that something like

globvar = foo.c header.h

build foo.o: CC $globvar

would stat a single (hypothetical) such file with a space inside its name. I still don't understand how a ninja variable can hold a sequence of (several) filenames.

I feel that behavior strange (and un-intuitive), for people with a make background (whose documentation mentions briefly spaces in its §6.2 the two flavors of variables section) My biased opinion is that build automation tool should ignore and reject (and perhaps warn against) any file path with a space (or blank, including tab or return or formfeed or space characters or any character responding to the isspace test from ctype.h) inside it (e.g. something obtained with touch 'stupid file name with spaces.c' in a unix shell).

Is my understanding correct? Then I suggest adding some notice about that in the tutorial (Since I am not a native English speaker, I don't know how to write that well). I lost a full day understanding that issue!

BTW, I would also suggest naming, in the tutorial section of ninja, the rules with some _rule suffix. For example, the first syntax example might be (using cc_rule instead of cc)

cflags = -Wall

rule cc_rule
  command = gcc $cflags -c $in -o $out

build foo.o: cc_rule foo.c

because at a first glance I thought (in the initial example using cc instead of cc_rule) that cc was some builtin for ninja (since e.g. it is a POSIX standard for the C compiler).

A big thanks for ninja and for reading this message. Cheers.

--

Basile Starynkevitch (Bourg La Reine, France) http://starynkevitch.net/Basile/

[Evan Martin]

Spaces in variables is discussed here (just after the table of special $$ etc syntax):

  https://ninja-build.org/manual.html#_lexical_syntax

As you observe, you cannot put a space separated list into a variables.

I also dislike spaces in filenames, but Ninja is used to build software that requires spaces in its filenames (in particular on OS X), so we cannot make it an error.

--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Basile Starynkevitch]

On 08/11/2018 02:36 AM, Evan Martin wrote:

Spaces in variables is discussed here (just after the table of special $$ etc syntax):

  https://ninja-build.org/manual.html#_lexical_syntax

As you observe, you cannot put a space separated list into a variables.

But that part of the documentation did not explain that

globvar = foo.c header.h

build foo.o: CC $globvar

does not behave like make

and that coding something like

othervar = header
build foo.o: CC $othervar.h

won't make foo.o depend on header.h

(that is, ninja don't simply do textual replacement on variables, like the sentence Ninja supports declaring shorter reusable names for strings -in section Writing your own Ninja files imply)


You remarked: but Ninja is used to build software that requires spaces in its filenames

but that could be handled in some other way (e.g. by requiring that such names have quoted spaces in them)

Cheers

-- 
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France

[Evan Martin]

On Fri, Aug 10, 2018 at 6:02 PM Basile Starynkevitch <bas...@starynkevitch.net> wrote:

(that is, ninja don't simply do textual replacement on variables, like the sentence Ninja supports declaring shorter reusable names for strings -in section Writing your own Ninja files imply)

I can see how you read it that way, particularly coming from make.  However, that section is intended to be an introduction to the syntax, so it didn't spell out all the limitations (for example, we also don't have the = vs := distinction that make has).  It might make sense to add a paragraph in there that links down to the reference.

 

You remarked: but Ninja is used to build software that requires spaces in its filenames

but that could be handled in some other way (e.g. by requiring that such names have quoted spaces in them)

I agree.