Re: New auxiliary archive script

[Ralf Wildenhues]

* Peter Rosin wrote on Thu, Aug 12, 2010 at 01:05:09PM CEST:
> Den 2010-08-12 05:29 skrev Ralf Wildenhues:
> > * Peter Rosin wrote on Wed, Aug 11, 2010 at 04:12:10PM CEST:

> Oh... oh! That means that AM_PROG_CC_WRAPPER and AM_PROG_CC_C_O should
> trigger 'compile' for completely different reasons, and that a projects
> should use AM_PROG_CC_WRAPPER to trigger support for MSVC (et al) and
> AM_PROG_CC_C_O should trigger it when the resulting makefiles require
> a compiler that supports -c -o.

Yes.

> Automake should be able to answer the latter question given its input,
> right?

Yes.

> IOW, is AM_PROG_CC_C_O really needed?

Not in the documentation recommending how to enable msvc support.
But Automake must continue providing it for backwards compatibility
to user configure.ac scripts which use it.

And ATM, with us currently supporting only MSVC through 'compile', it
is sufficient if both macros internally do the same thing for now.
The important bit is to document the intention of both macros as
different.

> (I understand that it might not be easy to get it right, and
> that it might just be a whole lot easier if the author has to add
> AM_PROG_CC_C_O whenever it is needed)
> 
> What I'm saying is that maybe AM_PROG_CC_C_O and AM_PROG_CC_WRAPPER
> shouldn't be synonyms.

I agree if we replace the last words with "shouldn't be documented to be
synonyms".

> > That's trivially (and fairly safely) fixed though.  I mean, is there
> > some real obstacle to also supporting 'link -lib'?
> 
> No, there's no real obstacle. The script could recognize 'link -lib'
> as a special combination and treat the pair as PROGRAM.
> 
> 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.

Cheers,
Ralf