Re: pr-msvc-support merge

[Gary V. Vaughan]

Hi Peter,

On 10 Jun 2010, at 20:55, Peter Rosin wrote:
> Den 2010-06-10 11:14 skrev Gary V. Vaughan:
>>>>>    8c17887ee34e73a2aeb127b94f5b76f45dc34017
>>>> 
>>>> Why so much cruft in ltmain.m4sh just to drive a different archiver?  It
>>>> seems to me that this would be better and easier to maintain, test and 
>>>> extend
>>>> as a whole new script.  Let's call it, $prefix/libexec/libtool/ar, build it
>>>> from $srcdir/libltdl/config/ar.m4sh, and have libtool set AR to point at 
>>>> the
>>>> script instead of /usr/bin/ar when the system is funky.
>>>> 
>>>> WDYT?
>>> 
>>> Sound appealing! I didn't want libtool to mess with $AR, so I introduced
>>> another layer of indirection through a new $LTAR variable that libtool
>>> can set to the "libtool --mode=ar" fallback for funky archivers. My way
>>> requires interaction with automake but that's not needed if there's no
>>> problem with libtool messing with $AR.
>> 
>> Well, I think we'll need a parallel patch for automake anyway, since automake
>> has lib_LIBRARIES which may very well call $AR without involving libtool at
>> all.
>> 
>> Which makes me think that once we have our wrapper working, it makes more
>> sense to contribute it to automake than release it with libtool.
> 
> If the libtool part of the configure script clobbers $AR with the wrapper
> script when needed, Automake can call $AR as much as it likes and it will
> work. Or what am I missing?

I'm thinking about people who'lll need a wrapped AR from automake to build
lib_LIBRARIES (as opposed to lib_LTLIBRARIES) when the project doesn't want
to use libtool at all.  Or maybe that makes no sense for a Windows build?

>>> Hmmm, the extra layer of indirection is orthogonal, isn't it?
>> 
>> I'm not sure exactly what you mean.  Certainly we (and eventually
>> Automake) will need to figure out what to put in AR, but while we
>> get it working, I see no harm in unconditionally using:
>> 
>>   'AR = $(auxdir)/ar'
> 
> What I mean is that $AR may have been set by the user before running
> configure to make a specific selection of the archiver. If the configure
> script then determines that the user-provided $AR needs wrapping, it
> needs to store this fact somewhere, and then you have contention for
> the AR name. Is $AR under the control of the user or the configure
> script?

Oh, I see.  AR is a user variable, and in that respect we should trust
that the user knows what they're doing if they set AR to something
specific on purpose.

> However, I guess the situation is very much the same as with
> $CC and the compile script and that seems to work. I just don't
> understand exactly how. Does it work because the CC make variable is
> not the same thing as the CC shell variable?
> 
> *looks around a bit*
> 
> No, that's not it, one instance of the libtool script has
> 
> CC="/c/cygwin/home/peda/libtool/git/libtool-msvc/libltdl/config/compile cl"
> 
> and I only said CC=cl when I configured...

I don't know how it works either, but I think you're right to mirror
the way automake handles CC.  Hopefully Eric or Ralf will jump in and
correct me if I'm off base.

>>> Your way is also a bit over the top of my head. I don't know how to
>>> create the infrastructure in the build system, so I'm going to need
>>> help with that...
>> 
>> With the idea of contributing the script back to Automake for use in
>> its lib_LIBRARIES rules, we shouldn't use the m4sh infrastructure, so
>> let's just encapsulate it in a self-contained script to be installed
>> alongside mdate-sh, depcomp and the like.  It looks pretty straight-
>> forward actually.
> 
> Hmm, does this mean that everything about getting support for MS lib
> as archiver ends up in Automake?

Mostly, but libtool will make use of it too in projects that use both.
And I think that libtool should pull the latest copy and distribute it
in it's release tarballs too, since we also want libtool to be useful
in non-automake projects (even non-Autoconf projects actually).

> One thing that I "fear" about not having the support built into libtool
> is that projects might need to invoke some extra macro (copy-paste-fix
> AM_PROG_CC_C_O). Old projects tend to have AM_PROG_CC_C_O since they
> needed to support some oldish toolchain many years ago, but how many
> maintainers are going to add AM_PROG_FUNKY_AR and the $auxdir/ar script
> at this point?

From (what I remember of) the inner workings of Automake, it's not
difficult to teach the automake invocation to notice the use of
_LIBRARIES or _LTLIBRARIES as it scans the Makefile.ams, and then
AC_REQUIRE the necessary macros from AM_INIT_AUTOMAKE.

Cheers,
-- 
Gary V. Vaughan (address@hidden)