autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Ignore boilerplate logo from MSVC on stderr.


From: Peter Rosin
Subject: Re: [PATCH] Ignore boilerplate logo from MSVC on stderr.
Date: Wed, 18 Aug 2010 08:38:20 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

Den 2010-08-17 22:01 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Mon, Aug 16, 2010 at 09:41:06PM CEST:
>> Den 2010-08-16 21:36 skrev Eric Blake:
>>> Rather than doing a sed for a particular regex, I would be much more
>>> comfortable with a comparison of the two outputs.  Less chance of
>>> Microsoft changing their output in such a way that would foil yet
>>> another regex.
>>
>> Yes, cmp would be nicer. But the current autoconf code is not at all
>> rigged for doing that easily. It's way beyond me anyway, and I dare not
>> attempt such an overhaul...
> 
> That's not a valid argument for not going this route though.  ;-)

Not in general, no. But in this case we have a sed program of 3-4
statements that *might* need adjusting when? In 7 years or so? 17?
One could also argue that we'll take the silly little program now
and postpone the proper solution until the sed program breaks.

It's also not fatal if the sed program fails (who cares about a couple
of warnings that will not even break it when you ask the tool to treat
warnings as errors), which is an argument for accepting an improper
solution (not too bad if it regresses), but also for rejecting it (who
needs it anyway).

> I'll try to look at it next weekend unless beaten to.

That's of course the best path. Thank you! But if you let it slide
I'll be Back With a Vengeance... :-)

> Also, note that this is really only relevant for AC_PROG_{CC,CXX} but
> not so much for other Autoconf macros: as soon as the 'compile' prefix
> is used, -nologo gets added.

Huh? If you you are trying to say that the compile script adds -nologo,
then you are misinformed. It could, but it currently doesn't...

> Maybe we should rethink things and suggest using a AM_PROG_CC_WRAPPER
> macro that can somehow work before AC_PROG_CC and add the wrapper ...
> in that case it would have to be different from AM_PROG_CC_C_O.

Would it be as simple as adding something like this before
AC_PROG_CC_G in the AC_PROG_CC definition?

m4_ifndef([AM_PROG_CC_WRAPPER], [AM_PROG_CC_WRAPPER])

(AM_PROG_CC_WRAPPER should then not be a synonym of AM_PROG_CC_C_O
of course)

Cheers,
Peter



reply via email to

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