Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Den 2010-06-08 18:19 skrev Christopher Hulbert: On Tue, Jun 8, 2010 at 11:03 AM, Peter Rosinp...@lysator.liu.se wrote: Den 2010-06-08 15:40 skrev Christopher Hulbert: On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosinp...@lysator.liu.sewrote: I've had enough frustration here, methinks. Sorry for my contribution to your frustration. I would just like to see windows support in the mainstream to be done right, and the attitude of just get that out the door first doesn't seem to be an approach in the right direction. I realize you have done a lot of work on that branch, and I am not trying to subvert it or criticize it. I was just trying to make the Windows libtool support better. But you are subverting it and you are criticizing it when you say that it should be done right. Of course it can be done better. That's true of all software. But you have to understand that I'm at a point where I since long have stopped adding new stuff since the pending queue is too long. It should be no surprise that I'm not happy to see others butt in and defer the queue even further. Rereading what I wrote, my point didn't come out right. What I wanted to criticize was the attitude of just merge it then go forward. For someone who has their own windows branch for some time now, I just don't feel that the emotional desire to just get your existing work into the master warrants that kind of approach. I don't know what the right-way to do Windows support is and you are probably far more knowledgeable than I am with libtool, so there's no way for me to say your stuff is wrong, bad, etc. FWIW, I butted in over a year ago with questions about the branch and my desire to support PGI and Windows compilers [1]. Only 2 people responded to my butting, but unfortunately (and understandably) neither of them I think wanted to get involved with it. Since the consensus seems to be to merge the pr-msvc-support branch, then perhaps you should find problems with it now rather than wait for it to be merged? You seem to want someone to look at your work to check if it fits with what's pending, and adjust so that your stuff merges easily later. But I get the feeling that we are past that stage and am not really interested in going back to the drawing board. I want to start using what's already implemented first. So if you want your work to fit with the future of libtool you will have to address specific issues now instead of the above hand-waving with the implication that the pending stuff is somehow bad. I already mentioned two problems that exist for me (no support for Intel or PGI compilers). Of course I want someone to look at my work or at least be interested in looking at it because it provides me support for building on Windows that I currently don't see available, but I fail to see how that is a bad thing. I want to share what I have done to possibly help other people. Obviously I am willing to get my hands dirty or I would not have started modifying libtool on my own. I am not saying what pr-msvc-support does is bad. I am saying that it does not provide the Windows support I needed. I would not mind helping to add my stuff to what you have, but I have posted several messages before related to Windows that have just dead-ended. If someone on the pr-msvc-support branch shows no interest in my work, and it is easier for me to start from libtool master with a clean slate, why would I bother trying to figure out what pr-msvc-support already had. I'm biased of course, but you all know that. I guess in the end, it doesn't matter to me. I will continue to do whatever I am doing. Sorry for the noise. Sorry if I'm stepping on toes here, but somehow this is a rather sensitive subject to me... I understand it may be a sensitive subject to you. I don't know how to say it again, but I am not criticizing or passing any other negative judgement on the pr-msvc-support branch. I am just saying that it does not support my Windows needs. I don't recall at the time I started my windows branch if I was aware of pr-msvc-support or not. Oh, and I will be much more open to collaboration once the branch has been merged. That's a promise. I guess I just don't understand that attitude. If it were me and someone else wanted to collaborate or help out on Windows support, interacting with them would be important to me. Then again, I don't really care if my windows changes make into libtool. I will continue to use whatever I have, and if pr-msvc-support gets merged with master I will just figure it out. I guess in the end it is just frustrating that few people on the libtool list care about Windows, and furthermore do not express an interest or invite collaboration. A year ago I had some questions on the pr-msvc-support branch and even provided some patches I had made to master at the time for PGI windows compiler support [1]. Only Bob and Ralf responded. Had you popped up as the owner of the branch and expressed interest in what I wanted
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, 8 Jun 2010, Gary V. Vaughan wrote: [[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, even if you install mingw cross toolchain on linux ? You can even test Windows CE with cegcc on linux Vincent Torri 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. Chuck, Peter, you both have commit rights, correct? Would you be willing to round up those pending patches and shepherd them into the tree? I'm planning to put out a new libtool point release every few months from now on, as long as something worthwhile has been added to the code since the previous release. Note, btw, that the only reason we haven't been deluged with complaints about that latter, is that cygwin and MinGW both distribute a forked libtool package that has been patched to deal with these issues. It is *routine* on cygwin to ALWAYS reautoconf EVERY package you try to build, mostly to pull in the working libtool instead of the official libtool the package shipped with. Yikes. Well, I'd like to fix that too. If the fork is well tested already (as seems to be the case), and we can verify that merging it back into git won't cause regressions on other platforms, I'd very much like to fold all of that back into 2.2.12 for sometime in early August. If one of you would create a topic branch for unmerged Windows patches and commit the things that belong in upstream, I'll test them on the platforms I have access to, and merge them back into master if there are no issues. Or, if it turns out that they are big and destabilizing, then I'll make a 2.2.x release branch for 2.2.12, and we can start thinking about a Windows friendly 2.4.0 towards the end of the year. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
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. 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
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Hi Vincent, On 8 Jun 2010, at 15:17, Vincent Torri wrote: On Tue, 8 Jun 2010, Gary V. Vaughan wrote: [[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, even if you install mingw cross toolchain on linux ? You can even test Windows CE with cegcc on linux Okay, perhaps can't was too strong. A better characterisation of my prior attitude to Windows patches is: I honestly have paid very little attention to Windows fixes for libtool because I don't have or want access to a Windows machine, and don't want to set up a cross compilation test environment on a Linux VM. I suppose I could buy a Windows license, and a VMWare license, and then install all of that good stuff with cygwin and/or msys and/or mingw, on my mac, but I genuinely have no interest in Windows these days. I do understand that Windows is very important for others, and I am willing to do all the release management and cross testing to ensure windows patches didn't regress on the dozen or so Unix platforms I do care about. And, I'm very happy that Peter and Chuck do have the inclination to look after the Windows side, and I'm hoping to support them better from here on out. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Den 2010-06-08 10:22 skrev Peter Rosin: 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... Thinking about it some more, I came to the conclusion that the obviously correct thing to do is to merge the new entries into ChangeLog.2009. If the branch is merged back, that is when the changes appeared, after all. It we instead decide to cherry-pick from the branch it's another story, then my request for advise will be applicable. Please advice. No longer needed, but thanks for your time anyway. :-) Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On 06/08/2010 02:22 AM, Peter Rosin wrote: 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. Do you have Bruno Haible's git-merge-changelog program installed on your machine? For the longest time, it was just a part of gnulib that you had to build and install on your own, but it will soon be coming into its own as a true package: http://lists.gnu.org/archive/html/bug-gnulib/2010-05/msg00200.html http://git.sv.gnu.org/cgit/gnulib.git/tree/lib/git-merge-changelog.c With that installed, and a couple of lines in your .git/config (or even globally in ~/.gitconfig), git can do the changelog merging automatically for you (although it does it in commit order, rather than date order). 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)... This is where the GNU Coding Standards are somewhat silent - they were written in a day of CVS, when commits were made to a central repository in strict order, so the date was always the date of the original commit. But nowadays, I'm personally fine seeing dates out of order, with the understanding that the dates track the first commit on _someone's_ checkout, but list the order of commits into the upstream canonical tree. However, I also tend to personally re-date my Changelog entries to the day that I'm pushing them upstream, but this can entail quite a bit of work for a lengthy patch series. And I do that by using 'git rebase -i', so although the committer and ChangeLog date are the day I push upstream, the author date is still my original date of writing the patch. And since 'git log' prefers author date over committer date, that means that I often see out-of-order dates in the git log. So I can go either way. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Den 2010-06-08 11:50 skrev Eric Blake: On 06/08/2010 02:22 AM, Peter Rosin wrote: 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. Do you have Bruno Haible's git-merge-changelog program installed on your machine? For the longest time, it was just a part of gnulib that you had to build and install on your own, but it will soon be coming into its own as a true package: http://lists.gnu.org/archive/html/bug-gnulib/2010-05/msg00200.html http://git.sv.gnu.org/cgit/gnulib.git/tree/lib/git-merge-changelog.c With that installed, and a couple of lines in your .git/config (or even globally in ~/.gitconfig), git can do the changelog merging automatically for you (although it does it in commit order, rather than date order). I have git-merge-changelog. But my changes on the branch are in ChangeLog, and the question was where they should be after the merge, in ChangeLog or in ChangeLog.2009. I was not asking how the merge should be performed with as little hassle as possible. 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)... This is where the GNU Coding Standards are somewhat silent - they were written in a day of CVS, when commits were made to a central repository in strict order, so the date was always the date of the original commit. But nowadays, I'm personally fine seeing dates out of order, with the understanding that the dates track the first commit on _someone's_ checkout, but list the order of commits into the upstream canonical tree. However, I also tend to personally re-date my Changelog entries to the day that I'm pushing them upstream, but this can entail quite a bit of work for a lengthy patch series. And I do that by using 'git rebase -i', so although the committer and ChangeLog date are the day I push upstream, the author date is still my original date of writing the patch. And since 'git log' prefers author date over committer date, that means that I often see out-of-order dates in the git log. So I can go either way. You don't seem to grok that the pr-msvc-support branch is upstream. Sorry for not being explicit about that, but please answer again when taking that fact into account. I don't want to rebase that branch just because someone rotated the ChangeLog. (But other issues with the branch might make it desirable to rebase it anyway, but that's beside the point.) Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
[adding Bruno, as author of git-merge-changelog] On 06/08/2010 04:14 AM, Peter Rosin wrote: I have git-merge-changelog. But my changes on the branch are in ChangeLog, and the question was where they should be after the merge, in ChangeLog or in ChangeLog.2009. I was not asking how the merge should be performed with as little hassle as possible. Interesting question; I do think that it makes more sense to merge entries into ChangeLog.2009 rotated file if the commit was made to the published branch prior to 2010, and you aren't rebasing that branch. 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)... This is where the GNU Coding Standards are somewhat silent - they were written in a day of CVS, when commits were made to a central repository in strict order, so the date was always the date of the original commit. But nowadays, I'm personally fine seeing dates out of order, with the understanding that the dates track the first commit on _someone's_ checkout, but list the order of commits into the upstream canonical tree. However, I also tend to personally re-date my Changelog entries to the day that I'm pushing them upstream, but this can entail quite a bit of work for a lengthy patch series. And I do that by using 'git rebase -i', so although the committer and ChangeLog date are the day I push upstream, the author date is still my original date of writing the patch. And since 'git log' prefers author date over committer date, that means that I often see out-of-order dates in the git log. So I can go either way. You don't seem to grok that the pr-msvc-support branch is upstream. Rather, pr-msvc-support is a published branch, but I still don't consider it on quite the same par as the 'master' branch. That is, you are correct that it would no longer be polite to rebase pr-msvc-support without good reason (and just fixing changelog locations doesn't qualify as a good reason on my part). But doing a 'git merge', where the new commit has a head of both 'master' and 'pr-msvc-support', and having that merge commit sort out all the ChangeLog contents, is reasonable. It gets tricky here, because gnulib doesn't really use git merge (automake does, but many other GNU projects are still using git in a linear manner). There may well be some shortcomings in git-merge-changelog for how it is used, in the face of rotated changelogs or in the face of 'git merge' rather than 'git rebase', that may need tweaking. Sorry for not being explicit about that, but please answer again when taking that fact into account. I don't want to rebase that branch just because someone rotated the ChangeLog. (But other issues with the branch might make it desirable to rebase it anyway, but that's beside the point.) I agree with the decision to not rebase; if we are okay with a merge commit, then I think the easiest thing would be to place all of the changelog entries from pr-msvc-support before any of the entries from master, then manually move any entries dated in 2009 to ChangeLog.2009 in that same order. But I'd wait to see if anyone else has an opinion. Another option might be to rewrite the merged ChangeLog, and not touch ChangeLog.2009, by marking all of the pr-msvc-support entries as merged entries with an indented date, in this manner: today's date merge pr-msvc-support pr-msvc-support date 1 commit message 1 ... pr-msvc-support date 2 commit message 2 ... previous master entry date master message 1 ... Again, maybe it's worth teaching 'git-merge-changelog' how to do this style of indenting dates to represent merges? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin p...@lysator.liu.se 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 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On 8 June 2010 09:17, Vincent Torri vto...@univ-evry.fr wrote: even if you install mingw cross toolchain on linux ? You can even test Windows CE with cegcc on linux FWIW, my experience is that the mingw cross toolchain on linux is not a close enough approximation of the real thing on Windows; the problems being that 1. Builds often involve running the built executables. There are a few possible solutions for this, but all of them are departures from what happens in a full native build. 2. Once you have a complete build, there are still many runtime issues, and to find those you obviously have to run the built executables. 3. You can use Wine to try to address (1) and (2), but that isn't a perfect emulation, and it's easy to run into problems that turn out to be Wine-specific. Therefore, if one is going to support Windows at all, I think it needs to be done with MinGW/MSYS on Windows. (For the sake of balance, I should say that it's pretty cool that you can run the cross toolchain and Wine on Linux, and that they get as close as they do. But some applications it may not be close enough.) Regards, Neil ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On 8 Jun 2010, at 15:22, Peter Rosin wrote: Hi Gary! Hey Peter! 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. 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)... That's my understanding of the rule too. In the (ancient) past with big CVS merges we used to put the merged changelogs at the top of the current ChangeLog file, with the date lines in the merged commits indented but otherwise unchanged... but I can't find any evidence of that in the rotated logs, so maybe we cleaned it up at some point? 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... I'm not sure what other projects do, and I don't really have a strong preference either way... but, I suppose, left entirely to my own devices I would merge the ChangeLogs to retain their date order (including the rotated out ChangeLog files). That way, the chronology of what happened is maintained in order, and git diff still shows what went into each branch and when the merges happened. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Hi Chris, Forgive my jumping in again here... On 8 Jun 2010, at 17:47, Christopher Hulbert wrote: On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin p...@lysator.liu.se 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. ...to 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. 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 (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughan g...@gnu.org 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 p...@lysator.liu.se 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. ...to 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. Chris 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 (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Hi Christopher! Den 2010-06-08 15:06 skrev Christopher Hulbert: On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughang...@gnu.org wrote: 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. So, me working around issus with your patches is better exactly how? 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. Hey, I have more stuff that I would like to add, but given that it has been virtually impossible to get any patch review for Windows stuff (Ralf has been the only one doing it, thanks!), maybe, just maybe, we shouldn't add too much to the plate? Which is also the reason why I have been mostly ignoring anything new on the Windows front. Sorry about the silence. There is already enough pending stuff, IMHO. Let's just get that out the door first. That may be frustrating for you, but the alternative is frustrating for me which is worse - of course :-) I've had enough frustration here, methinks. Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosin p...@lysator.liu.se wrote: Hi Christopher! Den 2010-06-08 15:06 skrev Christopher Hulbert: On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughang...@gnu.org wrote: 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. So, me working around issus with your patches is better exactly how? My apologies if that is what you took away from what I said. What I meant is that it is more work than the status quo. I can keep up with libtool master right now with ease, I don't know what would happen after the pr-msvc-branch was merged. I would like it if the few people interested in Windows support would collaborate more (more on that below). 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. Hey, I have more stuff that I would like to add, but given that it has been virtually impossible to get any patch review for Windows stuff (Ralf has been the only one doing it, thanks!), maybe, just maybe, we shouldn't add too much to the plate? Which is also the reason why I have been mostly ignoring anything new on the Windows front. Sorry about the silence. I agree that it has been hard to get any patch for Windows support reviewed. I think the lack of participation by people like myself who are interested in libtool on Windows has contributed to this. On the other hand, I would hardly consider myself capable of reviewing such patches. Libtool is a complex package that I know only enough to hack and get myself in trouble. There is already enough pending stuff, IMHO. Let's just get that out the door first. That may be frustrating for you, but the alternative is frustrating for me which is worse - of course :-) I've had enough frustration here, methinks. Sorry for my contribution to your frustration. I would just like to see windows support in the mainstream to be done right, and the attitude of just get that out the door first doesn't seem to be an approach in the right direction. I realize you have done a lot of work on that branch, and I am not trying to subvert it or criticize it. I was just trying to make the Windows libtool support better. I guess in the end, it doesn't matter to me. I will continue to do whatever I am doing. Sorry for the noise. Chris Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Hi Chris, On 8 Jun 2010, at 20:06, Christopher Hulbert wrote: On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughan g...@gnu.org wrote: 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. Both Peter and Chuck have commit rights, and might be interested in merging your changes into pr-msvc-support or master if you rebase them from one or the other and submit? Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Den 2010-06-08 15:40 skrev Christopher Hulbert: On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosinp...@lysator.liu.se wrote: I've had enough frustration here, methinks. Sorry for my contribution to your frustration. I would just like to see windows support in the mainstream to be done right, and the attitude of just get that out the door first doesn't seem to be an approach in the right direction. I realize you have done a lot of work on that branch, and I am not trying to subvert it or criticize it. I was just trying to make the Windows libtool support better. But you are subverting it and you are criticizing it when you say that it should be done right. Of course it can be done better. That's true of all software. But you have to understand that I'm at a point where I since long have stopped adding new stuff since the pending queue is too long. It should be no surprise that I'm not happy to see others butt in and defer the queue even further. Since the consensus seems to be to merge the pr-msvc-support branch, then perhaps you should find problems with it now rather than wait for it to be merged? You seem to want someone to look at your work to check if it fits with what's pending, and adjust so that your stuff merges easily later. But I get the feeling that we are past that stage and am not really interested in going back to the drawing board. I want to start using what's already implemented first. So if you want your work to fit with the future of libtool you will have to address specific issues now instead of the above hand-waving with the implication that the pending stuff is somehow bad. I'm biased of course, but you all know that. I guess in the end, it doesn't matter to me. I will continue to do whatever I am doing. Sorry for the noise. Sorry if I'm stepping on toes here, but somehow this is a rather sensitive subject to me... Oh, and I will be much more open to collaboration once the branch has been merged. That's a promise. Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, Jun 8, 2010 at 11:03 AM, Peter Rosin p...@lysator.liu.se wrote: Den 2010-06-08 15:40 skrev Christopher Hulbert: On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosinp...@lysator.liu.se wrote: I've had enough frustration here, methinks. Sorry for my contribution to your frustration. I would just like to see windows support in the mainstream to be done right, and the attitude of just get that out the door first doesn't seem to be an approach in the right direction. I realize you have done a lot of work on that branch, and I am not trying to subvert it or criticize it. I was just trying to make the Windows libtool support better. But you are subverting it and you are criticizing it when you say that it should be done right. Of course it can be done better. That's true of all software. But you have to understand that I'm at a point where I since long have stopped adding new stuff since the pending queue is too long. It should be no surprise that I'm not happy to see others butt in and defer the queue even further. Rereading what I wrote, my point didn't come out right. What I wanted to criticize was the attitude of just merge it then go forward. For someone who has their own windows branch for some time now, I just don't feel that the emotional desire to just get your existing work into the master warrants that kind of approach. I don't know what the right-way to do Windows support is and you are probably far more knowledgeable than I am with libtool, so there's no way for me to say your stuff is wrong, bad, etc. FWIW, I butted in over a year ago with questions about the branch and my desire to support PGI and Windows compilers [1]. Only 2 people responded to my butting, but unfortunately (and understandably) neither of them I think wanted to get involved with it. Since the consensus seems to be to merge the pr-msvc-support branch, then perhaps you should find problems with it now rather than wait for it to be merged? You seem to want someone to look at your work to check if it fits with what's pending, and adjust so that your stuff merges easily later. But I get the feeling that we are past that stage and am not really interested in going back to the drawing board. I want to start using what's already implemented first. So if you want your work to fit with the future of libtool you will have to address specific issues now instead of the above hand-waving with the implication that the pending stuff is somehow bad. I already mentioned two problems that exist for me (no support for Intel or PGI compilers). Of course I want someone to look at my work or at least be interested in looking at it because it provides me support for building on Windows that I currently don't see available, but I fail to see how that is a bad thing. I want to share what I have done to possibly help other people. Obviously I am willing to get my hands dirty or I would not have started modifying libtool on my own. I am not saying what pr-msvc-support does is bad. I am saying that it does not provide the Windows support I needed. I would not mind helping to add my stuff to what you have, but I have posted several messages before related to Windows that have just dead-ended. If someone on the pr-msvc-support branch shows no interest in my work, and it is easier for me to start from libtool master with a clean slate, why would I bother trying to figure out what pr-msvc-support already had. I'm biased of course, but you all know that. I guess in the end, it doesn't matter to me. I will continue to do whatever I am doing. Sorry for the noise. Sorry if I'm stepping on toes here, but somehow this is a rather sensitive subject to me... I understand it may be a sensitive subject to you. I don't know how to say it again, but I am not criticizing or passing any other negative judgement on the pr-msvc-support branch. I am just saying that it does not support my Windows needs. I don't recall at the time I started my windows branch if I was aware of pr-msvc-support or not. Oh, and I will be much more open to collaboration once the branch has been merged. That's a promise. I guess I just don't understand that attitude. If it were me and someone else wanted to collaborate or help out on Windows support, interacting with them would be important to me. Then again, I don't really care if my windows changes make into libtool. I will continue to use whatever I have, and if pr-msvc-support gets merged with master I will just figure it out. I guess in the end it is just frustrating that few people on the libtool list care about Windows, and furthermore do not express an interest or invite collaboration. A year ago I had some questions on the pr-msvc-support branch and even provided some patches I had made to master at the time for PGI windows compiler support [1]. Only Bob and Ralf responded. Had you popped up as the owner of the branch and expressed interest in what I wanted to do (even if you did not care
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On 6/8/2010 6:47 AM, Christopher Hulbert wrote:
Peter/Charles,
Do you have a summary of the capabilities added by your
patches/branch
I'll let Peter speak for himself, but these are the patches in the
cygwin and mingw distributions:
* Pass various runtime library flags to GCC. (-shared-libgcc, etc)
1 file changed, 4 insertions(+), 1 deletion(-)
Apparently there is some argument here about how the various
-shared-{runtimelib} and -static-{runtimelib} flags should be
handled.
* [cygwin|mingw] Refine UAC support.
1 file changed, 17 insertions(+), 4 deletions(-)
* [cygwin|mingw] Create UAC manifest files.
1 file changed, 33 insertions(+)
* Refactor cwrapper cross-compile support; Add cygwin.
4 files changed, 617 insertions(+), 131 deletions(-)
* [cygwin|mingw] fix dlpreopen with --disable-static take N
3 files changed, 282 insertions(+), 25 deletions(-)
The UAC patches were most recently discussed, but that discussion
wandered off into the weeds of how UAC should be documented in the .info
file, and we never got back around to actually considering the patch
itself. My plan was, once the UAC stuff was resolved, to go back to the
well and try to get the other three merged, one at a time.
Only...my ability to participate is somewhat bursty. When those bursts
are expended on...bikeshedding...it saps my will to continue bloodying
my forehead against the brick wall. So...there we have sat, for the
past few months, since my most recent burst.
--
Chuck
___
http://lists.gnu.org/mailman/listinfo/libtool
