[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: GNU make: Next release schedule.]

From: Paul Smith
Subject: Re: address@hidden: GNU make: Next release schedule.]
Date: Thu, 17 Sep 2009 19:00:49 -0400

On Fri, 2009-09-18 at 00:20 +0200, Juan Manuel Guerrero wrote:

> This patch contains the changes required to compile and run the testsuite
> using DJGPP.  It is basicaly the same that I have submitted almost two years
> ago.  I have removed the part to fix the broken path support for MSDOS/WINDOWS
> because this has already been fixed.

Thanks Juan.

I had a few thoughts about portability.  First, do you think it would be
appropriate to modify the test harness to set a different value for
$port_type, on DJGPP, other than 'DOS'?  Then that extra test could be
moved into the harness and the individual tests would only test

Or maybe backing up a step, what does the $port_type == 'DOS' mean?
Does it mean only DJGPP builds, or can it mean something else?  If it's
only DJGPP builds maybe the extra test for $ENV{DJDIR} should be
integrated into the harness (see run_make_tests.pl:set_more_defaults()).

Second, I think a better solution for the error message problem,
assuming it works, is to ask Perl what the right error message should
be, then just use that.  In the harness, for example, we can for a "no
such file or directory" error.  More portable than assigning an error
code to $! is to invoke the error:

        open(X, '<', 'ratsenfratzenfrie') and die "open worked!\n";
        $ENOENT_MSG = "$!";

Now you can use the string $ENOENT_MSG instead of "No such file or
directory", and hopefully it will always be the same string that the
local system uses, assuming that Perl uses the local invocation of
strerror(), like GNU make does.

Finally, I have some concerns about exiting from a test suite early if
we don't support parallel jobs, etc.  When I write a new test I
invariably just go to the end of the file and add it there; that means
that, unless we notice the situation, no new tests in those suites will
be run on DJGPP, even if they would otherwise work.

I think I'd prefer to see the code changed to put those tests into
if-statements and skipped that way, rather than returning early.

Thoughts about any of this?

I'm not necessarily saying you have to do this work since much of it
could be done by anyone.  However, we won't know if it all works (e.g.,
the handling of the error message) unless you or someone on DJGPP tests
it for us.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]