Would it be possible to have a special target .NULL_DELIMITED_LISTS to tell Make to use the null character as the list separator instead of whitespace?

That way we keep 100% backward compatability and also provide a simple way to support whitespace in filenames.  This would also allow more complex wildcard-ing such as:

    .NULL_DELIMITED_LISTS
   
    ...
   
    sources=$(shell find -name '*.in' {many predicates} -print0)
    targets=$(sources:%.in=%.out)
   
    ...
   
    %.out: %.in
        some-command < $^ > $@

Make would also automatically escape the whitespace in variables when building shell commands.

My workaround is to use a target that generates a local symlink to the file with spaces:

.PRECIOUS: %.link
%.link:
ln -s "$$(echo $@ | sed -e 's/_dot_/./g' -e 's/_slash_/\//g' -e 's/_space_/ /g' -e 's/.link$$//')" $@

# should depend on ../Plugin Source/metadata/monitor.xml but gnumake doesn't support spaces!
.DELETE_ON_ERROR:
%.sql: %.sql.haml Makefile $(wildcard _*.sql.haml) _dot__dot__slash_Plugin_space_Source_slash_metadata_slash_monitor.xml.link

"How hard is it to handle quoting properly?" - impossible if we wish to maintain backward compatibility.

As Paul said nearly 4 years ago, make works in terms of "words" which are whitespace separated.

The quotation that starts this comment is viewed by make as 8 words  , the first of which is 4 characters long, a double quote followed by the letters 'H', 'o' and 'w'.

"Heck, even DOS can accept quoted arguments.". Does it? I type

echo "fred x"

and it returns

"fred x"

rather than the

fred x

I would expect. And if I try and create a file called a"b from the command line it fails, if I try from wordpad it tells me the name is invalid. Unix allows any characters in components of filenames except NUL and /. Whilst this is very flexible it also causes problems. The people who wrote unix recognised this, and in their next operating system they restricted the characters permitted in filenames to not allow control characters and the normal whitespace characters. At the same time they extended the valid characters to include things like alpha α, which are outside the traditional ASCII character set.

How about simply:

$(notdir "C:\Program Files\Company Name\Binary1.dll" "C:\Program Files\Company Name\Binary2.dll") 

I think it's pretty clear what should happen here.  How hard is it to support quoting properly?  After all most shells know how to quote intrinsically, and GNU make is creating shell scripts for most things.

Heck, even DOS can accept quoted arguments.  Same argument for targets.  If I expect spaces, I (should be able to):

"%.util" : "$(TEMP_PATH)/%.exe"
  cp "$*" "$(OUT_PATH)/$(notdir $*)"

Seems natural enough, is this type of thing I need to do in most batch/shell/scripts anyway.

The manual is pretty clear that all parsing is done in terms of words, and words are space separated.  It is less clear as to whether spaces can be escaped, or how.

>> It's not well known to anyone who's read the manual. If
>> it's true, then the file naming limitations of make should
>> be PROMINENTLY and EXHAUSTIVELY detailed in the docs.

Yes, they should be.

<<it's well-known that GNU make simply does not handle files with spaces (or colons for that matter) in their names well at all.>>

It's not well known to anyone who's read the manual. If it's true, then the file naming limitations of make should be PROMINENTLY and EXHAUSTIVELY detailed in the docs.

Spaces are as valid in Unix filenames as Windows, and there is no short name to fall back on there.

The automatic variables $(@D) etc. are simply shorthand for other functions such as $(dir $@), and that's exactly how they're implemented internally.  If $@ expands to text with embedded whitespace, the dir function treats it as multiple arguments and returns the directory component of each argument.

I'll fix this for the next release.