[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: Eli Zaretskii
Subject: Re: PATH vs. Path ([Fwd: Returned mail: see transcript for details]
Date: Sun, 06 Mar 2005 21:04:51 +0200

> Date: Sun, 6 Mar 2005 09:31:04 +0200
> From: David Baird <address@hidden>
> > 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

Well, I asked the question because I thought it _was_ an important
question.  See below.

> 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.

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.

There's no way we could solve all of these problems in Make, so I
think we shouldn't try too hard.  We should assume that programs are
invoked via Path, and under that assumption give users a reasonably
reliable way of setting Path.  Situations where Path is not a reliable
solution will have to be solved in ways that don't involve Path.

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.

> 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.

Sorry, I'm not following.  It seems to me that if you can set Path so
that the correct directory is there for the program(s) to be found,
you can do the same with explicit absolute filenames, since that
requires to know that same correct directory.  Can you perhaps show an
example that explains your preference to set Path?  TIA

> > 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."

But that is exactly equivalent to saying ``use cmd.exe or else...''.

reply via email to

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