[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pr-msvc-support merge

From: Peter Rosin
Subject: Re: pr-msvc-support merge
Date: Thu, 10 Jun 2010 15:55:38 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100317 Thunderbird/3.0.4

Den 2010-06-10 11:14 skrev Gary V. Vaughan:

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.


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

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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]