[Top][All Lists]
[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
- pr-msvc-support merge, Gary V. Vaughan, 2010/06/09
- Re: pr-msvc-support merge, Paolo Bonzini, 2010/06/09
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/10
- Re: pr-msvc-support merge, Gary V. Vaughan, 2010/06/10
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/10
- Re: pr-msvc-support merge, Gary V. Vaughan, 2010/06/10
- Re: pr-msvc-support merge,
Ralf Wildenhues <=
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/11
- Re: pr-msvc-support merge, Ralf Wildenhues, 2010/06/12
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/14
- Re: pr-msvc-support merge, Ralf Wildenhues, 2010/06/14
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/16
- Re: pr-msvc-support merge, Charles Wilson, 2010/06/19