Re: pr-msvc-support merge

[Gary V. Vaughan]

Hi Peter,

On 10 Jun 2010, at 14:35, Peter Rosin wrote:
> Den 2010-06-09 16:46 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
>> done.
> 
> Then I suggest that we start with the archiver thing, as that is what the
> first patch on the branch is about (see below).

Ack.

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

Good point. Okay, it's your call.

>>>    8c17887ee34e73a2aeb127b94f5b76f45dc34017
>> 
>> 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.
>> 
>> WDYT?
> 
> 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
all.

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.

> 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
> ugly?

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'

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

Cheers,
-- 
Gary V. Vaughan (address@hidden)