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

[Christopher Hulbert]

On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin <address@hidden> wrote:
> Hi Gary!
>
> Den 2010-06-08 09:34 skrev Gary V. Vaughan:
>>
>> [[Adding Libtool List]]
>>
>> 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.

Peter/Charles,
  Do you have a summary of the capabilities added by your
patches/branch. I looked at the pr-msvc-support branch some time ago,
but had some issues getting it to work for what I wanted. I have my
own local branch that adds windows support. I recently sent an email
to the libtool list trolling for comments (particularly from you guys
which work with Windows as well) before committing changes for
manifest file embedding [1].

For my Windows branch I can:
  * Build libraries and executables using Microsoft, Intel, and PGI compilers.
  * Embed manifest files at a specific resource (e.g. 2 which supports
use with LoadLibrary).
  * Run testsuites depending on DLLs built (I had to fixup some things
for this, so it was not a gimme).

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. That's just my opinions though.

1. http://lists.gnu.org/archive/html/libtool/2010-03/msg00022.html

Chris

>
> There's already the pr-msvc-support branch, but when I tried to merge
> master into it to make it easy to merge back later, the ChangeLog rotation
> caused conflicts. How should I resolve those conflicts? By adding the
> entries to ChangeLog.2009 or to ChangeLog? I think the "rule" is to
> commit with the date preserved even if that causes the ChangeLog to
> be unordered, but I don't know how that "rule" applies in the face
> of a ChangeLog rotation (or two)...
>
> It seems odd both to (a) have entries from 2009 in the (future-to-be) 2010
> ChangeLog and (b) to make changes to the 2009 ChangeLog at this point.
>
> I see that for the first merge of master into the branch last year I
> updated the dates in the ChangeLog so that they said 2009, but that's
> lying. Sort-of anyway...
>
> Please advice.
>
> Cheers,
> Peter
>
> _______________________________________________
> http://lists.gnu.org/mailman/listinfo/libtool
>