From:	"Paul D. Smith" <pausmith AT nortelnetworks DOT com>
MIME-Version:	1.0
Message-ID:	<14275.64667.739010.922179@baynetworks.com>
Date:	Wed, 25 Aug 1999 10:24:27 -0400 (EDT)
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	Esa A E Peuha <peuha AT cc DOT helsinki DOT fi>,
	Laszlo Molnar <laszlo DOT molnar AT eth DOT ericsson DOT se>,
	djgpp-workers AT delorie DOT com
Subject:	Re: Make 3.78 is in pretest (fwd)
In-Reply-To:	<Pine.SUN.3.91.990825124504.2834M-100000@is>
References:	<14274 DOT 60469 DOT 134897 DOT 418721 AT baynetworks DOT com>
	<Pine DOT SUN DOT 3 DOT 91 DOT 990825124504 DOT 2834M-100000 AT is>
X-Mailer:	VM 6.73 under Emacs 20.4.1
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

%% Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> writes:

  ez> I will submit the necessary change.

OK.

  >> I can see two main options: 1) find all the necessary variables and
  >> preserve them, as we already do with HOME and PATH, etc., and make sure
  >> none of the tests use them

  ez> I prefer 1), since it is easier for a Perl-ignorant dude such as
  ez> myself, but won't this have adverse effects on Unix systems?

Only if any of the tests used variables with the same names as the ones
we preserve, then they might potentially conflict.  That's why I
mentioned "make sure none of the tests use them" :).

  ez> Unix assumes that Make's pathname is simply "make".  This is
  ez> incorrect in the DJGPP port, because argv[0] is always the full
  ez> pathname of the program.

Well, in UNIX the path in argv[0] is whatever you used to invoke make;
if you typed "make" it's "make"; if you typed "/usr/bin/make" it's
"/usr/bin/make".

  ez> For these reasons, it is dangerous to assume anything about what
  ez> $(MAKE) looks like, and it is better to cause Make itself to print
  ez> it.

OK.

  >> It makes me uncomfortable to add this as then the test is potentially 
  >> modified.

  ez> But GNU Makefile's all say "SHELL = /bin/sh", and I don't think this 
  ez> makes any problems with Unix environments.  So why is this a problem 
  ez> here?

Of course it shouldn't hurt anything for a properly configured make.
The GNU autoconf makefiles add this for the benefit of old, broken makes
that require it.

The question is, will having it explicitly set in the test suite mask a
potential misconfiguration with GNU make on some platform, that would
otherwise be flagged by the tests?  Hard to see how, I guess, unless
someone goes in and changes the default value of SHELL in the make
source code.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith AT baynetworks DOT com>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

- Raw text -