Hello, * Gary V. Vaughan wrote on Thu, Jun 10, 2010 at 04:35:41PM CEST: > On 10 Jun 2010, at 20:55, Peter Rosin wrote: > > 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.
That's pretty much an awful hack inside AM_PROG_CC_C_O, which overrides $CC if need be. > > 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. See above. It'd be nice to not have many more of those, if we can help it; but it seems to not bother too many users in practice, and if it's confined to MSVC ... > >>> 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. This sounds like a good idea to me. > > 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). That sounds good to me, too. It's just that if you need to transport information from configure to such a script that things get a bit hairy. We do it with 'depcomp' by setting variables in the commands that run it, but IIUC you would prefer that makefiles continue to work without changes. > > 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. Right. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool