Re: pr-msvc-support merge

[Peter Rosin]

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 have a patch somewhere that adds tracing to make all available libtool
> > modes detectable by automake and a 'tiny' automake patch somewhere else
> > that uses that to determine if the extra layer of indirection is
> > available, should I go digging for those patches or is "my way" just too
> > ugly?
>
> I dunno.  It's not the way I would have done it, but in the end you've
> done all the work, and you'll likely be the one who keeps it all working
> in the face of other changes to libtool down the line.  So you get to
> choose whether you'd like to put more work in up front to minimise the
> amount of maintenance you need later on.  Your call entirely :)
>
> > 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? 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...

Maybe this is a non-issue?

> > You should know that this ar wrapper thing is an alternative to
> > commit 0bb52ed03e71109ef75f8d72439ea1365ae14f42
> > with the core idea to use a new variable $AR_SEP to handle some of the
> > funkiness of the MS archiver. The problem with that is that $AR_SEP
> > needs to be a space in the normal case, and a single space is not
> > easily stored as the variable content in makefiles.
>
> I think we get to sidestep that whole issue by having the ar wrapper
> figure it out at runtime for the best flexibility and reusability of
> the same script when jumping between cygwin/msys/mingw etc.
>
> > 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?

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?

Cheers,
Peter