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 (g...@gnu.org) _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool