Re: PATH vs. Path ([Fwd: Returned mail: see transcript for details]

[David Baird]

> I know about this part, but I fail to see how setting Path would be a
> cure here: on Windows, one cannot be sure that programs are found by
> looking along Path, they can be found by some other rules private to
> the invoking program, like via the Registry or some
> installation-specific init files.

True, a development tool has to be properly installed. True, some of
them have init files and utilize the windows registry to find certain
parts. When I deploy a build system, I test these situations, and
learn to control them, or print error messages when I detect a
problem.

> I asked for details of your reasons for setting Path _precisely_
> because I wanted to have a better understanding of how Path is used in
> Makefiles: it is clear that if the value of Path outside Make is okay,
> there should be no need to modify it inside the Makefile.

I want to focus on fixing setting the Path environment variable in a make file.

I want to set the Path variable inside the make file because I cannot
be certain that it was set properly before running GNU Make.

I forgot to mention another way I like to control Path from make
files. I will set the Path to only the Windows system, and then call
all programs with full paths. I do this because I don't want
interference from what may be installed and in what order they appear
in the system wide Path variable.

> > So, don't tell them that. But do tell them, "If you use CMD.EXE, then
> > setting the Path environment variable will work."
> 
> But that is exactly equivalent to saying ``use cmd.exe or else...''.

No it isn't. Try: "For those that set SHELL to CMD.EXE in their make
file, they can be certain that setting the Path environment variable
in their make file will work in target rules and in $(shell) macros."

-David