libtool
[Top][All Lists]
Advanced

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

Re: pr-msvc-support merge


From: Ralf Wildenhues
Subject: Re: pr-msvc-support merge
Date: Fri, 11 Jun 2010 07:28:44 +0200
User-agent: Mutt/1.5.20 (2009-10-28)

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



reply via email to

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