automake-patches
[Top][All Lists]
Advanced

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

Re: New auxiliary archive script


From: Peter Rosin
Subject: Re: New auxiliary archive script
Date: Fri, 13 Aug 2010 11:38:43 +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-12 19:55 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Thu, Aug 12, 2010 at 01:05:09PM CEST:
>> Or always pass on any '-lib' option to PROGRAM w/o trying to interpret
>> it further. That might be a good addition, since there might be other
>> interesting options to pass through, and those could then be added to
>> the "exception list" the same way, e.g. -LTCG (or -ltcg, case don't
>> matter, link time code generation), -MACHINE and -SUBSYSTEM. But maybe
>> those options can be added after "cru" as is by setting ARFLAGS?
> 
> Yes, I suppose it is prudent for 'ar-lib' to pass through (or translate)
> all those flags which users might want to set and which are not
> problematic wrt. mis-parsing.  You already posted a patch for this.
> 
> Same with 'compile' by the way.  If -O3 is spelt differently for cl,
> then I think translating that is a good idea.  I don't recall which
> flags actually needed translation; if that actually includes -g or -O2
> then we have a problem, because AC_PROG_CC will test that before we get
> a chance to chime in.

I think we should keep such translation to a bare minimum. The chance
of options clashing is just too high, and that will cause end user
confusion.

E.g. "hey, I said LDFLAGS=-MD to specify that I want to link with the
MSVCRT.LIB runtime, but that does not seem to happen. Instead it links
with the default LIBC.LIB runtime which is not at all what I want. I
have noticed some spurious files with content which looks like dependency
info however, what are those?"

And should -MT take a parameter (as gcc does) or should it not (cl syntax)?

Also, there aren't going to be perfect matches for most options anyway.
It's just a losing game. And to further add to the burden, the translation
is likely to be dependent on compiler version.

-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...

So, this is all encapsulated in CFLAGS et al, and I think it should
be kept that way.

Cheers,
Peter



reply via email to

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