[Top][All Lists]

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

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

From: David Baird
Subject: Re: PATH vs. Path ([Fwd: Returned mail: see transcript for details]
Date: Sun, 6 Mar 2005 09:31:04 +0200

> Can you explain why you needed to set or export PATH or Path in the
> Makefile?  Was it different from the value outside Make, or was it
> because of some other reason?

I don't think this is really an important question for fixing this
problem, a good answer is, because that is how I want to use GNU Make.
However, perhaps I should explain how our, and many other, commercial
projects are using GNU Make on Windows.

Unlike Unix, controlling the environment on Windows can be rather
tricky, and unreliable. This is especially true of the Path variable.
As users install new software packages, especially development
packages, the Path variable can be change unpredictably.

This can be especially dangerous for reliable and reproducible
software builds, a requirement for commercial project development. For
this reason, it is very common to determine relevant environment
variables, like Path, in the make files, which allow a developer to
install whatever software they like, but still control which software
is used by the software build.

There are two schools of thought on this: the first is to call every
tool on the in the build rules with the tool's full path; the other is
to adjust the Path in the make file. The second approach is what I use
for two reasons: one is that many Windows tools also search for which
might not be in the same directory as the tool, and so require a
properly formatted Path. The other is that I place compiler other
helper tools in the source control, and don't want interference from
what is installed on the host Windows environment.

I don't want to rely on a batch file being run first, I don't want to
rely on anything. I want the make files to be self contained.

> > I therefore utilize the CMD.EXE for Windows, and my
> > make files work well.
> That might not work for situations different from yours.  One notable
> example is using Make to build ported GNU software: in that case,
> Makefiles almost always need a ported Unix shell (Bash) and auxiliary
> utilities (Fileutils, Grep, Sh-utils, find, etc.).

This may be an interesting example in another context, but not in
mine. I am not involved in porting GNU software to Windows. I am
suggesting that GNU Make supports my situation of using CMD.EXE for
building Windows based software projects.

> So we cannot tell users of the Windows port of Make ``use cmd.exe if
> you want PATH and $shell to work''.

So, don't tell them that. But do tell them, "If you use CMD.EXE, then
setting the Path environment variable will work."


reply via email to

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