automake-patches
[Top][All Lists]
Advanced

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

Re: pr-msvc-support merge


From: Peter Rosin
Subject: Re: pr-msvc-support merge
Date: Mon, 21 Jun 2010 10:07:19 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5

Hi Ralf!

Den 2010-06-14 22:40 skrev Ralf Wildenhues:
[ adding automake-patches; this is
   http://thread.gmane.org/gmane.comp.gnu.libtool.general/10927/focus=10954 ]

* Peter Rosin wrote on Mon, Jun 14, 2010 at 09:35:45AM CEST:
Den 2010-06-12 10:05 skrev Ralf Wildenhues:
Well, I sort of figured that the 'compile' script could end up absorbing
quite a bit of the cccl functionality so to make it unneeded.  But hey,
let's be honest, somebody would have to do this work, because I don't
have the resources to do it.

Do you think something along these lines would be acceptable? It would
remove the need of some patches on the pr-msvc-support branch...

The patch looks pretty good to me already, but is lacking additions for
ChangeLog, NEWS, and maybe doc/ and tests/ too.

Wrt. test suite exposure, here's my overall take on this for Automake:
Generally, the suite should try to cover each and every single code bit,
even error cases, as much as is feasible without big hassles.  Of
course, that'll only be realistic if you take the union of test suite
runs over all sorts of systems (but if some system-specific part can be
emulated elsewhere, that's great of course).  As a first step, if you
tell me that the patch fixes some failures of existing tests on some
system with
   env CC=cl make check

then that is fine with me too; as far as we have this information, it
should be noted in the log entry.

I have now run the test-suite once without the patch and once with
the patch. There was only one difference (that seem totally
unrelated). When I run that test by itself it behaves the same both
with and without the patch so I'll attribute the difference to
flakiness. The odd test was conff.test. Other than that test there
were 9 failures (and a bunch of skips and xfails).

FAIL: check8.test
FAIL: depcomp3.test
FAIL: distcleancheck.test
FAIL: lzma.test
FAIL: parallel-tests5.test
FAIL: specflg10.test
FAIL: suffix13.test
FAIL: xz.test
FAIL: check8-p.test

check8{,-p}.test uses AM_PROG_CC_C_O in its configure.in, and the
test detects that the compiler doesn't support -c -o, but the
compile script isn't used. Possibly because I have CC set in my
environment (to work around other issues). If I run the test with
CC="/path/to/compile cl" the test passes, but if I do that there
is no proper testing that AM_PROG_CC_C_O behaves as it should.

depcomp3.test fails since it requires gcc and the test therefore
changes CC from cl to gcc, but that's not enough since I also have
CFLAGS=-MD which means something completely different to these two
compilers. It seems fundamentally broken to assume that CFLAGS
remains sane while changing CC. Using CC="cl -MD" to hide the
problem would complicate the detection of cl in the proposed
compile script patch.

distcleancheck.test, parallel-tests5.test, specflg10.test and
suffix13.test falls over on auto-generated .manifest files.

lzma.test has this in its log (I don't know what's going on):
tardir=lzma-1.0 && /bin/sh /home/peda/automake/git/automake/tests/lzma.dir/missing --run tar 
chof - "$tardir" | lzma -9 -c >lzma-1.0.tar.lzma
lzma: (stdin): Not enough memory
WARNING: I can't seem to be able to run `tar' with the given arguments.
         You may want to install GNU tar or Free paxutils, or check the
         command line arguments.
make[1]: *** [dist-lzma] Error 1
make[1]: Leaving directory `/home/peda/automake/git/automake/tests/lzma.dir'
make: *** [dist] Error 2

xz.test fails in the same way as lzma.test.


The failure in check8 makes me think that I need to run the whole
testsuite once more but with CC="/path/to/compile cl" since I
suspect that the compile script isn't used at all when CC is
set in the environment. I'll do that over night though (I haven't
spotted any annoying popup dialogs, so there's no need for
marking tests 'interactive' from my point of view, *knock wood*)


I'll take a stab at writing a test covering the new features of
the compile script next.

Cheers,
Peter



reply via email to

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