Re: New auxiliary archive script

[Peter Rosin]

Den 2010-08-12 05:29 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Wed, Aug 11, 2010 at 04:12:10PM CEST:
>> One thing to consider is that the compile script is triggered "by chance"
>> for MSVC. It is just a lucky coincidence that MSVC doesn't support -c -o,
>> so that the compile script can add that support and then tag on the other
>> needed crap. I think the Intel C compiler on Windows has a similar option
>> set as MSVC, so it can probably be handled in much the same way. But if
>> the Window PGI compiler needs a wrapper, I don't think it will be
>> triggered by the current implementation of AM_PROG_CC_C_O.
> 
> That's a problem, but not a big one.  We can always add more tests to
> this macro that trigger a wrapper, as long as C compilers on unixes are
> not affected.  Adding a better-named synonym macro is prudent, too, such
> as maybe AM_PROG_CC_WRAPPER.

Agreed.

>> If people didn't like having 'compile' in their tarballs,
> 
> Well, people disliked having their compiler go through another wrapper.
> (Add to this that it could happen sometimes even though it was not
> necessary.)

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. Automake should be able to answer the
latter question given its input, right? IOW, is AM_PROG_CC_C_O really
needed? (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.

>> there can be
>> only one reason, -c -o is supported by all the compilers they need. In
>> which case they have not previously needed MSVC, or have that covered by
>> other means, i.e. a separate build system. Maybe more projects will
>> move over to using an autotooled build system for MSVC, but that is far
>> from certain.
> 
> Well, I know a few Linux kernel module packages are built with automake.
> I can understand why they wouldn't be interested in MSVC support, and
> would see additional code to that end as a waste.

Agreed.

>> It all comes down to if we want (1) or (2). I obviously find (2) very
>> appealing but as I stated above, I don't think this is my call.
> 
> Well, let's reformulate the question then: while (2) is appealing, (1)
> seems conceptually cleaner.  Would you mind having to adjust packages
> for solution (1)?  I imagine most users wouldn't, given that the
> prospect is going from two build systems to one with a two-line change
> in configure.ac and a re-bootstrap.  And possibly other adjustments
> they'd need to make anyway (see also the thread referenced below).
> 
> So, unless you object strongly, let's go with (1).

Yes, you are right. I don't expect many packages to just work out of the
box with these autotools changes. And those that do are likely to have
some developer that will be rather quick to add a new macro. Maintainers
of packages needing more changes will probably not barf on a couple of
added lines in configure.ac if they take the other needed stuff, and for
the rest one can always do .../configure CC="/path/to/compile cl" etc...

I guess I'm settling for (1).

>> Hasn't autotools lost quite a bit of market share to CMake because
>> it hasn't supported MSVC?
> 
> Probably, but market share is not an issue I think we should take into
> account when deciding *how* to implement something, rather than deciding
> *what* do work on.

Right, I don't know why I brought it up...

>> On the other hand, CMake produces MSVC
>> project files, maybe that is seen as a killer feature?
> 
> Well, I inquired about this recently on the automake list:
> <http://thread.gmane.org/gmane.comp.sysutils.automake.general/11885>
> So far most feedback seems to be that they would likely be happy when
> this is implemented!  :-)

Yes, I'm following that thread with interest. But I don't have much to
add as David Byron already said the stuff that I would have said...

>>> Finally, does your wrapper work with 'link -lib' too?
>>
>> No it doesn't, ar-lib then thinks only 'link' is the program and
>> then tries to interpret '-lib' as ar actions -> boom.
> 
> 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?
I haven't tried that...

Or...

>>> Then, when we have all these sorted out: would you be willing to write
>>> testsuite additions to cover as many of the semantics as possible
>>> (warn about misordering, recommend AM_PROG_AR, use it without or with
>>> Libtool, etc)?
>>
>> I will certainly try.
> 
> Thanks.  If you need help or would like to share the load please feel
> free to say so.  You can also always post patch versions you have.
> (But please do start a new thread.)
> 
> FWIW, for users of Libtool that don't use Automake, it should still be
> possible to use the wrappers by using only
>   AM_PROG_CC_C_O
>   AM_PROG_AR
> 
> and letting aclocal install the needed macro definitions.  For this to
> keep working it would be good to ensure that these macros don't require
> AM_INIT_AUTOMAKE to be present (would make a good test, too).

I am likely to need help, yes. Let's see how far I get and if I
can go fast enough...

Cheers,
Peter