Re: Environment variables in makefiles with DOS

[Greg Chicares]

On 2007-05-18 12:59Z, Earnie Boyd wrote:
> Quoting Eli Zaretskii <address@hidden>:
[...]
>> Btw, would using a function work here?  Something like this:
>>
>>  include $(SOURCE_ROOT)/$(file "Main Line")/default.mk
>>
>> where the hypothetical function $file just returns its argument.
>> Would this work?
> 
> I think it might assuming the function $file returned the 8.3 version of
> the name.

Might this provide the optimal answer to the recurring questions
about paths with embedded blanks?

$(dospath name...)
  Return an alias for file 'name'. On systems that encourage
  embedding blanks in paths, and provide an alias with no blanks,
  return that alias if available; otherwise, return the argument.
  All characters in 'name' are treated as part of a single argument,
  so this function can even accommodate a name like "a, b, c".

Users who really want to use paths with blanks often try quoting,
then find that quoting solves few of the problems. Would a builtin
function like this solve most of the problems? It's unnatural, but
perhaps no less unnatural than necessary.

Here's a classic example:

  # This doesn't work as hoped.
  VPATH = My Source Files
  # Quoting doesn't help.
  VPATH = "My Source Files"

  # But wouldn't this work?
  VPATH = $(dospath My Source Files, version X)
  # It would expand to something like this:
  VPATH = My~7

I can think of at least one problem it might not solve. Suppose a
dependency file is created in '/build~2' and refers to '/src~3/a.c'.
If new directories like 'build my stuff #6' and 'src 3.x' are later
created, then AIUI that might cause the original "short" names to
change, invalidating the dependency files.

Perhaps there are similar problematic scenarios with makefiles that
create and destroy directories whose names have embedded spaces.
Still, if the issues are finite and can be described, would such a
builtin function be worth adding?