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

[Peter Rosin]

Den 2010-11-17 06:35 skrev Paul Eggert:
> On 11/16/2010 01:49 AM, Peter Rosin wrote:
>> We have a proposed patch that fixes problems.
> 
> If this is talking about the patch proposed in
> <http://lists.gnu.org/archive/html/autoconf-patches/2010-08/msg00023.html>

Yes, that's the patch, sorry for not adding the reference myself.

> then I'm afraid that I'll have to demur.  That
> patch quite possibly could cause more problems,
> long-term, than it would cure.

Since it can only cause problems for the poor sods running tools that
outputs something Microsoftian, I don't see why you care given your
below statements.  Or am I missing something?

>  I suggest instead
> that you cobble together a working compiler.

That's a rather saddening (and surprising) statement from an autoconf
maintainer...

> One possibility is to use GCC.

Yeah, let's all use the same OS too, just for good measure.  I'm sorry,
but while some aspects of MS tools are inferior, other aspects are
superior.  I like choice.

>  Another is to put the
> Microsoft compiler inside a shell-script wrapper
> that filters out the undesirable copyright message.
> Or you can try configuring with CFLAGS=-nologo, which is
> (obliquely) suggested in
> <http://lists.gnu.org/archive/html/autoconf/2010-11/msg00015.html>.

I know all about workarounds.  The trouble is that when there are many
workarounds, other people (i.e. not me) get the impression that things
are not even close to working.  Which leads to people sneering about
cobbling together working tools.  And that's pretty sad when it is so
close to working.  In fact, just the other day I built a couple of
libraries with MSVC with simple

  autoreconf -i; configure CC=cl CFLAGS=-nologo [more stuff]; make

sequences.  The autoreconf step will not be needed once the libraries
in question pick up latest released autotools.  I don't think this
is what most people trying to build those libraries expect.  In fact,
I think most people would assume that it wouldn't work at all and thus
not even try.

The more warts we can get rid of the better, so that the minimum
required configure arguments can be reduced as much as possible.

> I am sure that you can come up with something better than
> that August proposed patch.

And while I get to grips with the autoconf source, new autoconfs
will continue to be released with known problems with known solutions.
(and with that I'm /not/ promising that I'm going to attempt a patch
that gets through the eye of the needle)

Cheers,
Peter