[Top][All Lists]

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

Re: Incorrect use of CreateProcess() call in make?

From: Greg Chicares
Subject: Re: Incorrect use of CreateProcess() call in make?
Date: Sat, 10 Jan 2004 11:53:27 -0500

Jani wrote:
> YOu'd expect make to use the tools that can be found in PATH, and those
> only. I found out that make uses java.exe from my Windows system32
> directory, whether or not a different java.exe can be found in PATH, even
> if the system32 directory is not in PATH at all.

Makefiles commonly define variables like
  CXX = g++
and use them to invoke programs. Implicit rules use such variables,
for instance, compiling a C++ file with a command like
This makes it easy to change tools at the command line, e.g.
  make CXX='/some_path/some_compiler'
or you can define them the way you like in a makefile.

> The problem is, if CreateProcess() is given a file name without directory
> path, according to MS developer network, the system searches for the
> executable in the directory where make executable was found, in the
> current directory, both Windows system directories and the Windows
> directory BEFORE looking at the PATH. So, very easily, a wrong version of
> a compiler or any tool could be used.
> Whenever make uses a shell to execute commands, no problems arise.
> Apparently cmd.exe respects the PATH setting.

One could design an operating system to work differently, I suppose,
but that's the way windows is.

> Clearly this problem could be worked around using either full paths to the
> tools or using a separate batch file to call the tools or forcing the use
> of a shell (i.e. cmd /c), but this isn't very neat.

Loading a shell each time would be inefficient.

If you want to use the first instance of a tool found on $(PATH), you
might try to adapt this example from the make manual:

  pathsearch = $(firstword $(wildcard $(addsufix /$(1),$(subst :, ,$(PATH)))))
  LS := $(call pathsearch,ls)

The way the directories in $(PATH) are delimited depends on your shell.

> If my interpretation of what's going on is correct, I'd say this is a bug
> in the Windows port.

Or a feature of the windows OS.

reply via email to

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