Date: Wed, 25 Aug 1999 13:10:53 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Paul D. Smith" 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: <14274.60469.134897.418721@baynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Tue, 24 Aug 1999, Paul D. Smith wrote: > Well, what does the DOS port do when you give -j? Currently, it silently ignores it. > 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? Yes, but the message should be different, since the above text doesn't make sense for __MSDOS__ (even if sh.exe is available, multiple jobs aren't supported). I will submit the necessary change. > Then the tests could check for that output and ignore it? Yes. > 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. I prefer 1), since it is easier for a Perl-ignorant dude such as myself, but won't this have adverse effects on Unix systems? If so, what would be the best way of making that part DOS-specific? > 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. Unix assumes that Make's pathname is simply "make". This is incorrect in the DJGPP port, because argv[0] is always the full pathname of the program. However, the exact form of argv[0] can be different, depending on the precise definition of $PATH known to the program that invoked Make (in this case, it's Perl). Depending on this and several other subtle factors, several functionally equivalent but literally different forms of argv[0] may be seen. For example, it could use forward- or back-slashes, be in upper-case or in lower-case, etc. For these reasons, it is dangerous to assume anything about what $(MAKE) looks like, and it is better to cause Make itself to print it. This is what the snippet above does. > 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? If the other platforms don't mind, neither do I ;-). > ez> + print MAKEFILE "SHELL = /bin/sh\n"; > > Hmm. Is this necessary? Yes. > How will the tests work without a shell (will they)? They won't. These lines are necessary in those tests which use shell features in Makefiles, like quoting $ with another $, redirection of stderr of the commands invoked by Make, etc. Without this line, Make will assume that it needs to use the emulation of the stock COMMAND.COM shell, which doesn't support these features; so the tests fail. In other words, the DJGPP port of Make assumes the stock DOS shell as the default, and only switches to Unix shell if the value of SHELL says that explicitly. The reason is that most users don't use Bash and don't know enough about it to make their command lines Bash-safe. > I guess I'd rather see that on the command line only for DOS, > rather than in each makefile. If you want to say "make SHELL=/bin/sh", then this won't work: we need to give the exact pathname of Bash on the target system. SHELL= inside Makefile's is treated specially in the DJGPP port (because so many Unix Makefile's say it), but if SHELL is set in the environment or on the Make command line, it is expected to point to the actual pathname of the shell, like on Unix. And most DJGPP installation don't have a /bin directory. So if we choose to go this way, we will need to add some code to the driver to find the actual path of Bash, and then pass that name on the Make command line. > It makes me uncomfortable to add this as then the test is potentially > modified. But GNU Makefile's all say "SHELL = /bin/sh", and I don't think this makes any problems with Unix environments. So why is this a problem here?