libtool-patches
[Top][All Lists]
Advanced

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

Re: 280-gary-test-old-m4-interface.diff


From: Peter Ekberg
Subject: Re: 280-gary-test-old-m4-interface.diff
Date: Thu, 29 Sep 2005 18:23:43 +0200
User-agent: Mutt/1.5.10i

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: address@hidden@
> >>+
> >>address@hidden@: address@hidden@
> >>+   $(LINK) address@hidden@
> >>+
> >>address@hidden@:
> >>+   $(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




reply via email to

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