Folks,
Another problem developing Winelibs app while using your Wine tree. Say you have the following: -- a Winelib app you're working on -- a Wine tree you're working on -- you compile wine out-of-tree
Now, say you build your myapp.exe.so OK, and you now want to create a symlink myapp -> winewrapper so you can start your Winelib app. Problem is that winewrapper resides in the source tree, and there is no way for it to figure out where the build tree is, and it needs that.
Possible solution: -- have winewrapper somehow in the Wine build tree. One way to do that is to rename winewrapper to winewrapper.in, and generate winewrapper at build time -- link to the winewrapper in the build tree -- modify winewrapper slightly so that it looks where is resides, and if it's in the wine tree, is should try to use that to run the app. Alexandre, what do you say?
"Dimitrie O. Paun" dpaun@rogers.com writes:
Possible solution: -- have winewrapper somehow in the Wine build tree. One way to do that is to rename winewrapper to winewrapper.in, and generate winewrapper at build time -- link to the winewrapper in the build tree -- modify winewrapper slightly so that it looks where is resides, and if it's in the wine tree, is should try to use that to run the app.
Alexandre, what do you say?
You shouldn't use winewrapper, you should copy wineapploader and adapt it to your situation. This is what winemaker is supposed to do too, though I think it's somewhat broken right now.
On November 21, 2002 05:12 pm, Alexandre Julliard wrote:
You shouldn't use winewrapper, you should copy wineapploader and adapt it to your situation. This is what winemaker is supposed to do too, though I think it's somewhat broken right now.
OK, that's better. I don't need winemaker for this, I don't want to redefine their entire build process. People are are quite attached to their build process, you know... :)
Now, what I don't like is to ship them that script. There's no need, really, all they have to do is link to it. And for it to work right out of the tree, I can just add a small thingy in wineapploader that looks at where the symlink is pointing, and tests if a wineserver is available. We require too many changes in the way people build apps, and that's no good if we want them to build on Winelib. We got to keep is real simple, and non-invasive. KISS rules. ;)
Is that acceptable?
"Dimitrie O. Paun" dpaun@rogers.com writes:
Now, what I don't like is to ship them that script. There's no need, really, all they have to do is link to it. And for it to work right out of the tree, I can just add a small thingy in wineapploader that looks at where the symlink is pointing, and tests if a wineserver is available. We require too many changes in the way people build apps, and that's no good if we want them to build on Winelib. We got to keep is real simple, and non-invasive. KISS rules. ;)
Actually it's a bit more complicated because wineapploader expects a normal Wine installation, not to run inside the source tree. But I'm not convinced we should really go out of our way to support running inside the source tree; IMO we should encourage people to install Wine properly before building Winelib apps.
On November 21, 2002 06:05 pm, Alexandre Julliard wrote:
Actually it's a bit more complicated because wineapploader expects a normal Wine installation, not to run inside the source tree. But I'm
I know, but it can be modified to support running out of the tree without loss of functionality.
not convinced we should really go out of our way to support running inside the source tree; IMO we should encourage people to install Wine properly before building Winelib apps.
If Wine was a mature, stable project, I'd agree with you. But it's not. The ability to make a small change in Wine, go back to the Winelib app, and test it, is invaluable. I would have simply given up debugging PuTTY f I had to go through a wine install for every little test and experiment I was making.
But beyond that, the audience for these changes are *Windows* developers. These guys know Win32, and it's probably easier for them to fix a small header problem and submit a patch, rather then complain on wine-devel. These are exactly the guys we want experimenting with Wine to get their apps to work, and for this sort of thing, you have to work out of the tree. I know I always do, I'd waste way too much time to do an install every single time.
"Dimitrie O. Paun" dpaun@rogers.com writes:
If Wine was a mature, stable project, I'd agree with you. But it's not. The ability to make a small change in Wine, go back to the Winelib app, and test it, is invaluable. I would have simply given up debugging PuTTY f I had to go through a wine install for every little test and experiment I was making.
Sure, but as Wine developer it's easy for you to write a small wrapper script to run from inside the source tree. That doesn't mean we should encourage it or make that the default behavior. I think it's perfectly standard to expect that you need to install a library before building an app that uses it, all other libraries behave that way. And we are not going to stabilize our environment if nobody ever uses it the way it's intended to be used.
On November 21, 2002 07:07 pm, Alexandre Julliard wrote:
Sure, but as Wine developer it's easy for you to write a small wrapper script to run from inside the source tree.
The discussion got too theoretical. All I am saying is that right now, working with Winelib is not pleasant. I can talk from personal experience. And I think it's in our best interest to remove any unnecessary hoops that you have to jump through to get apps compiled with Winelib. It's just gonna get us more programmers.
Please keep in mind that for you, such changes are trivial. However, Wine is a very, very complex beast, and even these things take time, effort, and patience to figure out. And these are finite resources. I'd much rather have developers worry about other things, then how to make their app work with their Wine tree. For development, this is an important point, and there's nowhere to turn to to figure this one out. I've gone through the exercise, and it took me while. Plus with Visual-MinGW which was dying on startup, I didn't know that my script was OK. Hell, I didn't know that I was supposed to use wineapplauncher until you told me! :)
I've appended the patch I had in mind for wineapploader. It's small, doesn't hurt no one, and just helps people that want to work on Winelib. It's untested, but that's what I have in mind.
--- programs/wineapploader.in.orig 2002-06-09 01:41:57.000000000 -0400 +++ programs/wineapploader.in 2002-11-21 19:43:28.000000000 -0500 @@ -48,5 +48,19 @@ esac if [ -x "$appdir/wine" ]; then exec "$appdir/wine" "$appname" "$@"; fi
+# now try to see if we're running out of the tree +appnm=`basename "$0"` +winedir=`ls -l "$appdir/$appnm" | sed 's/.*->//'` +winedir=`dirname "$winedir"` +winedir=`cd $winedir/.. && pwd` +if [ -x "$winedir/miscemu/wine" ]; then + LD_LIBRARY_PATH="$winedir/dlls:$winedir/library:$winedir/unicode:$LD_LIBRARY_PATH" + WINEDLLPATH="$winedir/dlls" + WINESERVER="$winedir/server/wineserver" + WINELOADER="$winedir/miscemu/wine" + export LD_LIBRARY_PATH WINEDLLPATH WINESERVER WINELOADER + exec "$WINELOADER" "$appdir/$appname" "$@" +fi + # finally look in PATH exec wine "$appname" "$@"
"Dimitrie O. Paun" dpaun@rogers.com writes:
The discussion got too theoretical. All I am saying is that right now, working with Winelib is not pleasant. I can talk from personal experience. And I think it's in our best interest to remove any unnecessary hoops that you have to jump through to get apps compiled with Winelib. It's just gonna get us more programmers.
True, it's not pleasant, and one of the reasons is that nobody has really worked on making it pleasant. It's very good that you are looking into it, I'm just trying to encourage you to make it pleasant the right way, instead of simply hiding the unpleasantness under a few scripts that won't fix the core issues.
Of course creating a symlink is somewhat easier that copying and modifying a script, but it's not really that user-friendly either, we should be able to do better than that. I don't know exactly how yet, but it won't be trivial, and adding the requirement to run out-of-tree is going to make it even harder. So I think we should concentrate on making the "normal" way work well first.
On November 21, 2002 08:20 pm, Alexandre Julliard wrote:
It's very good that you are looking into it, I'm just trying to encourage you to make it pleasant the right way, instead of simply hiding the unpleasantness under a few scripts that won't fix the core issues.
It looks like you have made up your mind, but I have to raise this point, and this is as good as an occasion as any other.
I fully agree with you: the current way is lacking, we need a better way, let's not hide it under the rug. 100% with you. But there are at least two orthogonal issues here: 1. The current way of dealing with Winelib is lacking 100% with you. However, as you said, the solution is not trivial, so it's probably far in the future. I think we have far larger problems to solve, and forcing people to look into this one it may not be the best thing for Wine. Frankly, I'd rather work on the listview, and tree view, I think those are a lot more visible than this one, right? 2. The ability to link a Winelib app to a in-tree Wine Now, even if we had the perfect solution for (1), I would say this is still needed. And it's needed because Wine is not a stable library that you install, and work with. You have to make numerous tries, and experiments, and _anyone_ doing anything with Winelib will need this ability for the near future.
I'd love for (1) to get solved, but I don't have the time, and expertise to do it now. And even if I had, there are other items with higher priority on my TODO. My focus is on (2). The only reason I looked into compiling Winelib apps is to gather some experience, crystallize it in the form of fixes for the Wine tree (so that other don't have to go through the pain), and hope that people will start porting more to Winelib.
This is our only chance for Wine to become an accepted platform. And we, the Wine project, simply don't have the resources to go and compile every Win32 app under Wine. But we can try to make it easy for others to do so, and hope that they do. How we should go about this is the subject of a different mail, so I will not go into it here. However, I have to note that in the current state, we are not in the position to invite developers to use Winelib. I know, the solution I propose is not perfect, but remember: perfect is the enemy of good. If you have another solution, I'd love to hear about it. But it the meanwhile, what I've proposed might just do the trick for the next year or so. And when we have to change it, well, we'll cross that bridge when we get to it.
It would be so much more beneficial to us to get a bunch of apps using Winelib now, rather then in 1-2 years when we devise the perfect scheme. And don't forget, with those apps we also get a lot of Win32 developers.
"Dimitrie O. Paun" dpaun@rogers.com writes:
I'd love for (1) to get solved, but I don't have the time, and expertise to do it now. And even if I had, there are other items with higher priority on my TODO. My focus is on (2). The only reason I looked into compiling Winelib apps is to gather some experience, crystallize it in the form of fixes for the Wine tree (so that other don't have to go through the pain), and hope that people will start porting more to Winelib.
The thing is, I don't think your patch is enough for that. If we ask Windows developers to start porting their stuff now, they will run into major problems and they will leave in disgust, with or without your patch.
I agree that fixing Winelib is not the number one priority, but we have to recognize that we won't attract the Windows crowd until we fix it properly. A couple of hacks here and there won't cut it.
And really, I don't think it's necessarily that much work to fix it; the main issue is identifying the problems and defining exactly what we need it to do. And I think the right approach is to have Wine developers like you try to port apps, because you know how to work around the problems; giving that task to a Windows developer at this point is not going to work IMO.
On November 21, 2002 09:20 pm, Alexandre Julliard wrote:
the main issue is identifying the problems and defining exactly what we need it to do. And I think the right approach is to have Wine developers like you try to port apps, because you know how to work around the problems;
We are on the same page then! :) I've already submitted patches/bugs for the other problems. But there's only one where we have a bit of a stumbling block: I found out that working out of the tree is very useful. I'm certain other Wine developers will find the same. Your answer is "Don't do it!". which I don't think is reasonable given the current state of affairs. So then I ask: how can those Wine developers figure out how to run out of the tree? Where should they turn to? Should each and every Wine developer go through the pain, wasting time, trying to answer this very question? If you want to put this functionality in another script, that's fine with me, but I would like to have a place to (1) collect what I've discovered in my experiments, and (2) point people to when they are trying to do what I have done.
Don't get me wrong: I'm not arguing for the pleasure of arguing here. I'm just looking for a solution for the above problem. I'd like to be able to document on the Fun Project Page how one goes about compiling a Winelib app. And having such useful scripts in the tree would help a lot.
"Dimitrie O. Paun" dpaun@rogers.com writes:
I found out that working out of the tree is very useful. I'm certain other Wine developers will find the same. Your answer is "Don't do it!". which I don't think is reasonable given the current state of affairs.
No, I agree it's useful, and I'm willing to apply a patch if it's clean enough (your first one isn't really IMO). I just don't agree that it's a necessary fix to make Winelib usable, because it's not the normal usage; and IMO we should encourage people to use the normal way even if it's a bit more painful at first. But we can certainly have a patch for people like you who persist in using it the wrong way <g>
Am Fre, 2002-11-22 um 00.41 schrieb Dimitrie O. Paun:
If Wine was a mature, stable project, I'd agree with you. But it's not. The ability to make a small change in Wine, go back to the Winelib app, and test it, is invaluable. I would have simply given up debugging PuTTY f I had to go through a wine install for every little test and experiment I was making.
For me it was quite ok to do a "make install" only in the dll subdirs where I had modified something.
Martin
On Fri, Nov 22, 2002 at 09:45:01AM +0100, Martin Wilck wrote:
Am Fre, 2002-11-22 um 00.41 schrieb Dimitrie O. Paun:
If Wine was a mature, stable project, I'd agree with you. But it's not. The ability to make a small change in Wine, go back to the Winelib app, and test it, is invaluable. I would have simply given up debugging PuTTY f I had to go through a wine install for every little test and experiment I was making.
For me it was quite ok to do a "make install" only in the dll subdirs where I had modified something.
<aol>me too</aol> In the dlls subdirs i also normaly type "make install" instead of "make". Ok, it's a word more to type but it was easier for me to using it in the "natural way" aka installing wine, then to figure it out how to run it directly from the sources.
bye michael
-
Alexandre Julliard -
Dimitrie O. Paun -
Martin Wilck -
Michael Stefaniuc