Re: pr-msvc-support merge

[Ralf Wildenhues]

* Peter Rosin wrote on Mon, Jun 21, 2010 at 10:07:19AM CEST:
> 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.

Well, I guess configure does set CC='.../compile cl', but the problem is
that the test then runs 'make -e' later on, which overrides that.  Ouch.
That's purely a testsuite issue though.

> 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.

Correct.  Another testsuite issue.

> Using CC="cl -MD" to hide the
> problem would complicate the detection of cl in the proposed
> compile script patch.

But nonetheless, it is easy enough to allow such usage, by adding
  cl\ * | */cl\ *

cases to the patch.  We should do that.

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

OK.

> 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.

I've seen this before on MinGW; also, there is anyway a bug report
pending in this area to make the -9 configurable; I'll deal with that
later.

> 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 think that is relevant only for tests using '$MAKE -e' .

> 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*)

Good.

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

Thanks,
Ralf