From: "Paul D. Smith" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14274.60469.134897.418721@baynetworks.com> Date: Tue, 24 Aug 1999 15:02:13 -0400 (EDT) To: Eli Zaretskii Cc: Esa A E Peuha , Laszlo Molnar , djgpp-workers AT delorie DOT com Subject: Re: Make 3.78 is in pretest (fwd) In-Reply-To: References: <14266 DOT 61356 DOT 636908 DOT 533905 AT baynetworks DOT com> 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 Precedence: bulk %% Eli Zaretskii 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 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.