[Top][All Lists]

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

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

From: Christopher Hulbert
Subject: Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Date: Tue, 8 Jun 2010 09:06:16 -0400

On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughan <address@hidden> wrote:
> Hi Chris,
> Forgive my jumping in again here...

No problem, at least the subject is being talked about.

> On 8 Jun 2010, at 17:47, Christopher Hulbert wrote:
>> On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin <address@hidden> wrote:
>>> Den 2010-06-08 09:34 skrev Gary V. Vaughan:
>>>> On 8 Jun 2010, at 08:42, Charles Wilson wrote:
>>>>> Which is why I don't think even the Peter's long-ready MSVC patches, nor
>>>>> my pile of pending patches, are candidates for this extremely shortened
>>>>> release cycle.
>>>> Regarding these patches, I honestly have paid very little attention to
>>>> Windows fixes for libtool because I can't test them, and don't use them:
>>>> So I figured someone else was taking care of it.  Since that obviously
>>>> isn't the case, and because I'd hate to see them bitrotting indefinitely
>>>> in the list archives, we can either commit them on the trunk after 2.2.10,
>>>> or else create a topic branch in git to collect them together for testing
>>>> and merging back at an appropriate point.
>> [[snip]]
>> Anyways, I would like before this is merged into master to perhaps
>> have more activity on this topic and maybe try to merge features
>> provided by both Charles' and my own changes. Again, I think more
>> activity and publicity for the topic branch (including maybe a couple
>> releases from that branch) would be better than a near-term merge into
>> master.
> clarify my release plans.  Once the pr-msvc-support branch has had
> master merged into it, and Peter and/or Chuck tell me they are happy with
> the state of it on Windows, then I'll run through the complete testsuite
> with the head of that branch on all the Unix platforms I have access to.
> If there are significant regressions, then I'll create a 2.2.x maintenance
> branch for future 2.2.x releases, and merge pr-msvc-support into master
> for eventual inclusion in libtool-2.4.0.  Otherwise, I'll make the next
> 2.2.x release from master in a few months with pr-msvc-support already
> merged.
> I think it important to merge pr-msvc-support into master one way or
> another so that it doesn't get ignored for any longer than it has already.

I would like it to not get ignore longer either, but just looking at
the branch after pulling, I still don't see a hint of support for
either Intel or PGI compilers on windows, both of which my changes
support. That means I will likely have to continue to keep a local
branch with all my changes. In addition, I might have to work around
any issues created from the merge of the pr-msvc-support branch.
Obviously making more work for 1 person shouldn't stop libtool
progress, but I think taking the time to come up with a plan on what
will be supported when the branch is merged in and making it useful
for people like me using other native Windows compilers (again, Intel
and PGI) would be nice. No matter what, I am sure I can work
with/around whatever happens, but I would certainly prefer that the
official libtool have more Windows support than at least I can see
from the pr-msvc-support branch.


> In any case, I'm hoping to make point releases every few months from now
> on for as long as 2.2.x continues to accumulate fixes and ports.
> Cheers,
> --
> Gary V. Vaughan (address@hidden)

reply via email to

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