On Thu, Sep 29, 2005 at 05:10:47PM +0100, Gary V. Vaughan wrote: > Hi Peter, > > Thanks for the review!
Trying to chip in... > [[snip]] > > Peter Ekberg wrote: > >On Thu, Sep 29, 2005 at 03:35:37PM +0100, Gary V. Vaughan wrote: > >>+AT_DATA([Makefile.in], > >>+[[COMPILE = @CC@ @CPPFLAGS@ @CFLAGS@ > >>+LINK = @CC@ @CFLAGS@ @LDFLAGS@ -o $@ > >>+ > >>+all: [EMAIL PROTECTED]@ > >>+ > >>[EMAIL PROTECTED]@: [EMAIL PROTECTED]@ > >>+ $(LINK) [EMAIL PROTECTED]@ > >>+ > >>[EMAIL PROTECTED]@: > >>+ $(COMPILE) -c $< > >>+]]) > > > > > >Can we not use libtool compile/link mode instead so that the > >test does not break with my MSVC patches? I mean, since the > >test is for the m4 interface, or is this somehow part of the > >m4 interface? > > No it isn't part of the m4 interface, but neither does it build > or link with any libraries/library objects. I'm not sure it would > be correct to call libtool in that case. How do your MSVC patches > cope with compiling regular objects and linking regular executables? > Can you suggest what you think I should be doing here? I just realized there where no "difficult" switches, so scrap that. Sorry. > >The other issue I found was the checking of stdout, which does not > >seem to be portable, but I think Ralf covered that in his review. > > I think Ralf just meant that I wasn't checking the return status > of lt_dlexit(). Why is checking stdout non-portable? There are EOL issues, basically the tested programs output \r\n but the testsuite writes the expected output with \n on MSYS. Cheers, Peter
