Re: New auxiliary archive script

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

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

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

> For one thing, it's going to be slower than separately
> maintained MSVC project files. But I hate separate build systems -- it
> is bad enough to maintain one for a project -- and I (obviously) want to
> do "configure; make" for MSVC.

Agreed.

> But others are obviously entitled to their own opinion and *I* am not
> going to force 'compile' and 'ar-lib' on them if loads of users don't
> want them.

Please don't get me wrong, this isn't about devaluing your contribution
at all.  Rather, it is about flexibility that users may want (or even
need) vs. ease of use or ease of transition.

> Anyway, I'm too biased to vote on this issue.

Understood.

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

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

> 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!  :-)

> > 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'?

> > Can we think of a situation in which it may be useful to have the
> > configure.ac author (rather than the user invoking configure) modify
> > the set of tools we try for $AR?  Then we should leave a macro argument
> > IF-FAILS for that purpose, defaulting to error.
> 
> That seems like overkill to me, why shouldn't such a change be done
> in upstreams libtool from the start? Do you worry about configure.ac
> authors having to wait for a new libtool version to be released?

No.  In fact, I think we'll be able to provide releases for both
versions in timely-enough manners so that this shouldn't be an issue.

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

Cheers,
Ralf