From:	"Paul D. Smith" <pausmith AT nortelnetworks DOT com>
MIME-Version:	1.0
Message-ID:	<14274.60469.134897.418721@baynetworks.com>
Date:	Tue, 24 Aug 1999 15:02:13 -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.990822103808.6405C-100000@is>
References:	<14266 DOT 61356 DOT 636908 DOT 533905 AT baynetworks DOT com>
	<Pine DOT SUN DOT 3 DOT 91 DOT 990822103808 DOT 6405C-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> These leave one problem unsolved: what to do with
  ez> features/parallelism that cannot work in the DJGPP version.  Paul,
  ez> do you have any suggestions how to handle this without causing the
  ez> tester wonder whether Make is broken?

Well, what does the DOS port do when you give -j?  I see this for w32:

  #ifdef WINDOWS32
    /* look one last time after reading all Makefiles */
    if (no_default_sh_exe)
      no_default_sh_exe = !find_and_set_default_shell(NULL);

    if (no_default_sh_exe && job_slots != 1) {
      error(NILF,_("Do not specify -j or --jobs if sh.exe is not available."));
      error(NILF,_("Resetting make for single job mode."));
      job_slots = 1;
    }
  #endif /* WINDOWS32 */

Maybe something similar should be done for DOS?

Then the tests could check for that output and ignore it?

  ez> In addition, I have several mysteries to ask about, probably
  ez> because I don't know too much about Perl.  They are all connected
  ez> to the following fragment from test_driver.pl:

  ez>     sub toplevel
  ez>     {
  ez>       # clean out the environment

  ez> then everything works.  It seems like the value of $Path (which isn't
  ez> defined on MSDOS) somehow causes $PATH to be emptied.  Laszlo, can it
  ez> be that environment variables are compared case-insensitively
  ez> somewhere in Perl?  If so, this is a bug.

This is a perl-on-DOS thing; I don't know.

  ez> The other question I have about this is why does the script remove all
  ez> the variables from the environment?

Because it's possible that the user has some environment variables set
which can effect the results of the tests.  Recall that all environment
variables are imported as make variables, which could upset some of the
tests.

  ez> This undefines some crucial variables like SHELL and COMSPEC,
  ez> which are important for correct operation of Make.  For example,
  ez> if echo.exe is not installed, almost all tests fail because "echo"
  ez> is not found, although it is an internal command in both Bash and
  ez> COMMAND.COM: Make cannot run "echo" because it needs to find the
  ez> shell to invoke for this, and it looks for the shell using $SHELL
  ez> and $COMSPEC.

  ez> If the script relies on the default "/bin/sh" to come to the rescue,
  ez> then this doesn't work on DOS/Windows, where we cannot rely on /bin
  ez> being available.

Make needs to know how to invoke something to run its commands.  I don't
have any real thoughts on these issues, except as below.

  ez> Other environment variables, like $DJDIR, $USER, $HOST, and probably
  ez> some more, are also important for smooth operation of various DJGPP
  ez> utilities and library functions.  I can be sure that if these are
  ez> undefined, something will sooner or later break.

  ez> Can somebody suggest a way out of this predicament?  Is it possible
  ez> to not empty the environment at all?

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, or 2) create a namespace for make variables
that is either illegal for environment variables (containing "." for
example) or clean out those from the environment (all vars starting with
"_" for example) and make sure all the tests use variables in that set.
My concern with this is the tests are now ever-so-slightly less
wide-ranging than before.

  ez> +    # Find the full pathname of Make.
  ez> +    open(MAKEFILE,"> makefile.tmp");
  ez> +    print MAKEFILE "all:\n"
  ez> +                  . "\t\@echo \$(MAKE)\n";
  ez> +    close(MAKEFILE);
  ez> +    &attach_default_output ("makepath.tmp");
  ez> +    $code = system "$make_path -f makefile.tmp";
  ez> +    &detach_default_output;
  ez> +    $make_path = &read_file_into_string ("makepath.tmp");
  ez> +    $index = index ($make_path, "\n");
  ez> +    if ($index > 0)
  ez> +    {
  ez> +      $make_path = substr ($make_path, 0, $index);
  ez> +    }
  ez> +    unlink ("makepath.tmp");
  ez> +    unlink ("makefile.tmp");

Can you explain why this is necessary?  The UNIX and NT tests don't need
to do this, for example.

  ez> !   if ($fancy_file_names)
  ez> !   {
  ez> !     $tmpfilesuffix = "tmp";     # the suffix used on tmpfiles
  ez> !   }
  ez> !   else
  ez> !   {
  ez> !     $tmpfilesuffix = "t";
  ez> !   }

Is there any reason to not make the tmpfilesuffix "t" for all platforms?
  
  ez> + print MAKEFILE "SHELL = /bin/sh\n";

Hmm.  Is this necessary?  How will the tests work without a shell (will
they)?  I guess I'd rather see that on the command line only for DOS,
rather than in each makefile.  It makes me uncomfortable to add this as
then the test is potentially modified.

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