Den 2010-08-13 20:02 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Fri, Aug 13, 2010 at 11:38:43AM CEST:
*snip*
> On the other hand, this means that better support for cl means adjusting
> a number of macros from Autoconf, Gnulib, and maybe Automake as well.
> For example, what about dependency tracking?  Does the current code
> enable msvcmsys or msvisualcpp depmode if --enable-dependency-tracking
> is specified?  Your "MSVC status" post on libtool-patches doesn't tell.

--enable-dependency-tracking triggers msvcmsys for me, and it appears to
not have been broken since we fixed it, whenever that was...

>> -g does not mean anything to cl, which is fortunate. Unfortunately it only
>> prints a warning on stderr, so the autoconf test thinks it's ok to use it
>> which means that you get that warning all over the place unless you help
>> the -g test or override CFLAGS manually.
>>
>> cl : Command line warning D9002 : ignoring unknown option '-g'
>>
>> There is autoconf code to look for output on stderr when testing if -g is
>> a viable option, but unfortunately cl always outputs a logo on stderr,
>> unless you feed it -nologo, so the autoconf test only works if you set
>> CC="cl -nologo".
>>
>> Given that the stderr code seems to have been added to autoconf in response
>> to a cl report, that code seems rather broken...
> 
> Hmpf.  Not sure what to do; for the moment an addition to install.texi
> to specify CC="cl -nologo" CFLAGS= would probably be prudent.

CFLAGS= is not needed, since the -g test works with "cl -nologo", and -O2
is only added for $GCC. Is that -g warning really so bad, that we have to
mention it in the docs?

IMHO, the time is better spent fixing the autoconf test to not use -g if
stderr output changes at all when -g is used, instead of not using -g if
stderr output appears with -g but not without. Then we can forget about
the doc change...

Cheers,
Peter

Reply via email to