[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 09:35:05 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100317 Thunderbird/3.0.4

Hi Gary!

Den 2010-06-09 16:46 skrev Gary V. Vaughan:
Hi Peter,

[[Adding libtool list]]

On 9 Jun 2010, at 20:21, Peter Rosin wrote:
Den 2010-06-09 14:50 skrev Gary V. Vaughan:
As far as I can tell, you are eminently more qualified than me to know
whether your patches are likely to have issues.  If we can't do a straight
merge from your branch to master after 2.2.10 is rolled, then I suggest
you cherry pick as you see fit to a new merge-branch branched from current
master, but ping the list before you pull the trigger if there's anything
you want to iron out first.  When you have everything in order, I'll test
the result on all the hosts I have access to... if I hit any problems, we
can iron those out on the list too, and then merge to master when we're

Then I suggest that we start with the archiver thing, as that is what the
first patch on the branch is about (see below).

This is all assuming that your changes are deep.  If not, and you think it
will be easier and/or faster to cherry pick straight into master discussing
as we go, I'm happy to do that too, although branching and merging are so
easy in git that we'd have to absolutely sure that we're not making master
any worse than the previous commit each time we add to it.

The first three are probably not that bad, but the last one (8c17887...)
needs...further discussion. It was discussed, but it dead-ended as usual [1].
Here's a mid-point message [2] that is good if you get interested and want
to find the start of that discussion...

(*) fbc144008bd66848111fb8ef2d7293b33957ea1a

The way you skip the last reload part of the test makes it look as though
the entire test-group has been skipped.  I think you should put the reloadable
object test inside a separate AT_SETUP/AT_CLEANUP, and skip just that part.

Doesn't that mean that all the compiling/linking has to be done twice, once
for each AT_SETUP? Is it worth it? Anyway, we'll get to this in due time I
suppose. Let's take care of the older patches first...


This is just documentation?  I'd rather the documentation is added (maybe
in several stages) along with the code changes that require that documentation.



Looks good.

Good to know, but it depends on the other stuff... So, it will have to wait.


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.

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

Hmmm, the extra layer of indirection is orthogonal, isn't it?

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.

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...


reply via email to

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