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
