Mail Archives: djgpp-workers/1999/08/25/11:46:24
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?
- Raw text -