libtool
[Top][All Lists]
Advanced

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

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


From: Peter Rosin
Subject: Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Date: Wed, 09 Jun 2010 13:18:03 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

Den 2010-06-08 18:19 skrev Christopher Hulbert:
On Tue, Jun 8, 2010 at 11:03 AM, Peter Rosin<address@hidden>  wrote:
Den 2010-06-08 15:40 skrev Christopher Hulbert:

On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosin<address@hidden>    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
personally for the changes), and perhaps helped me along integrating
with your branch none of this would probably be an issue for me.

I never claimed that what I had done was better than what you had
done, but without someone else interested who looks at it and
comments, suggests, etc. I don't know any better.

1. http://lists.gnu.org/archive/html/libtool/2009-05/msg00049.html

Anyways, this thread seems to have become just a back and forth and
apparently I am coming across too critical. In the end, I will
maintain whatever I have for my own purposes. So not that I had any
standing to object from the beginning, but I will just let the issue
die.

I'm sensitive to further delays, I meant nothing else. In fact I'm
extremely sensitive to further delays. Which is also why I'm being
defensive and rude, it probably has nothing to do with how you are
coming across. I have watched so many patches and bug reports
whistle by with timely responses that it's simply not funny anymore.
I respect that my patches are complex and not interesting to everybody,
and we're all volunteering so there's noone to blame. But it's
frustrating all the same, perhaps even more frustrating exactly
because there is noone to blame...

Negative critique is another matter, I can take that easily (I think).
You haven't pointed out any specific issues with the branch, you have
only said that you want more features added before we merge. I also
want more features, but at this point I'm not all that happy to
destabilize anything as that could be used as an argument to push the
merge even further into the future.

What I'm saying is that I think you need to wait. Just get used to it,
it's not that uncommon around here. Ask Markus Duft...

One problem is that "Windows" is very diverse.

I think you want to drive native compilers from Cygwin(?). That would
be nice. Markus Duft wants to drive native compilers from Interix. The
problem with both your approaches is that you really are doing a cross
build, *and* the tools expect paths in the $host format. Doing cross
builds is not that pleasant and many packages don't work in that
scenario, so you lie and pretend that you are not cross-building, and
you get it to work reasonably. But not completely, you will have corner
cases where it will be...less than ideal [1]. You might even have
convinced yourself that you are not doing a cross build. Even if you
admit that you are doing a cross build, you are not doing a normal
cross build since the tools expect paths in $host format, which is not
how cross tools normally behave. The cross tools normally want $build
paths, not $host paths.

MSYS is also lying about doing cross builds, but at least it is
designed to do that, which makes me think that it's a better starting
point to drive the scripting of naive Windows tools than either of
Cygwin and Interix.

Further, Chuck's cwrapper cleanup patches have some ideas that will
remove some (most?) of the problems with MSYS lying about cross builds,
since not even MSYS (which is designed to lie) is always successfully
lying. If we extend those ideas a little bit and teach libtool that
there are tool chains that expect $host paths, we can move on to
supporting your case as well, I think. I have patches building on
top of Chuck's pending stuff that make Cygwin usable to drive MSVC. That
would also make Wine more useful, since it too can be used to drive
MSVC (or other native Windows compilers). In fact it should extend
nicely to all of the above options to drive the libtool script for
native Windows compilers.

Crawl -> Walk -> Run -> Fly

So unless you see some specific problem with the pr-msvc-support
branch or with Chuck's patches that will make adding your stuff
later very difficult, I really really want to merge what's there first.
If you are serious about doing some of the heavy lifting, maybe
you should start by filing the necessary paperwork? If you haven't
done so already, that is...

The apparent reluctance to collaborate seems mutual. You have said
about as much about my patches as I have said about yours, IIRC. Our
last conversation ended with a mail from me [2].

I'm also not a gatekeeper for Windows patches. I'm not a libtool
maintainer so I'm little more trusted to shepherd patches into the
tree than you are. And given the history of my branch, I didn't
want to drag your much simpler patches into that black hole. I'm not
going to say "Hey, I'll take your patches and add them to the end of
my queue!" when my queue isn't moving at all. That's simply not
friendly. One of the maintainers could have decided to take your
patches, after all.

Your patches work for you. Fine. But I expect that they fail on
various stuff in the test suite, which is a hint that they might not
work so well for others. My patches are more complex since they
attempt to pass the whole test suite. They still don't pass 100%,
but I expect them to be *much* closer than yours, and a couple of
years ago I decided to not go after the last failures until the
bulk of the work was accepted so I don't think it's a design flaw.

I have also worked on interface compatibility with MinGW, which is
the dominant way to build native windows software with libtool.
E.g. with my patches you can say (approximately anyway, not tested)

CC=cl
CFLAGS=-MD -Zi
libtool --mode=link $CC $CFLAGS foo.c -o foo.la -lcrypt32 -no-undefined

which is damn near

CC=gcc
CFLAGS=-g
libtool --mode=link $CC $CFLAGS foo.c -o foo.la -lcrypt32 -no-undefined

I expect that with your patches libtool will fail to locate Crypt32.Lib
or CRYPT32.LIB (depending on MSVC/PSDK version), which means that you
will need to adjust the build system for a lot of packages, possibly
depending on which MSVC/PSDK version you are using (with -lCrypt32 or
CRYPT32.LIB or something) in order to cope. Substitute with an import
library of your own choice, of course. These are just examples, and
I'm clearly speculating here as I haven't tried your patch, but I
expect trouble in important corner cases with any "small" patch claiming
"Windows support".

Regarding messages dead-ending, you are not alone (and you are not
innocent either, see [2]). It is not only Chuck that has blood on
his fore-head you know. I for one am only interested in one thing
at this point, and that is exactly to get the pending stuff merged
and then move forward. It might surprise you, but I'm not surprised
if Chuck feels as I do. If all this makes you feel ignored, then
so be it.

Cheers,
Peter

[1] http://lists.gnu.org/archive/html/libtool-patches/2006-02/msg00113.html
[2] http://lists.gnu.org/archive/html/libtool-patches/2009-09/msg00060.html



reply via email to

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