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: >> [[...]] we can begin to evaluate whether to use pr-support-msvc-branch >> in 2.2.12, or wait for 2.4.0. > > I don't really care how the merge happens as long as something is moving > forward. We can take it one commit at a time if that suits you. It's the > complete stand-still that is demoralizing. One small problem with that > is that some work needs to be taken from merge commits that has resolved > conflicts. I'm keen to keep the momentum going too. 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. 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. > 06cfce005204bb8ca212aadab38b38c0202ea04e This is just documentation? I'd rather the documentation is added (maybe in several stages) along with the code changes that require that documentation. > 2817364bb6efd255550192c46edecfe085cbb288 Looks good. > 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? Cheers, -- Gary V. Vaughan (g...@gnu.org) _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool