Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine. The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.). Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is "self-contained". The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs. As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path. Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime? On a related note: would it be possible to have a means to tell the wineserver process to "hang around" for a few seconds after the last wine process using it has terminated? Again, in this make process you get lots of "start wine, start compiler, compile, exit. Start wine, start compiler, compile, exit" operations - if the wineserver stuck around for 2 seconds after the last wine process terminated, this would aviod starting and stopping the wineserver process.
On Thu, 14 Feb 2002, David D. Hagood wrote:
Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine.
The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.).
Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is "self-contained". The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs.
Pity you couldn't use some other environment variable. The entire unix environment is available in the windows app's environment, but PATH is significant to windows apps, I guess, so wine takes the windified version of it from the config file to replace the *NIX value. If your compiler would look in, say MYPATH, a shell script could easily set that how it liked. *nix current directory is another possibility you should consider. If it happens that it can be accessed somewhere on a Wine drive, Wine will use it as the windows current directory, which is on the windows path, I think, implicitly. If not it will use the windows directory and write a mesage to that effect.
As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path.
Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime?
On a related note: would it be possible to have a means to tell the wineserver process to "hang around" for a few seconds after the last wine process using it has terminated? Again, in this make process you get lots of "start wine, start compiler, compile, exit. Start wine, start compiler, compile, exit" operations - if the wineserver stuck around for 2 seconds after the last wine process terminated, this would aviod starting and stopping the wineserver process.
start wineserver -p before starting any compiles, it will serve until it is killed. kill it with -INT or -TERM, please, not -KILL. -KILL will force it to leave a stale socket you will have to remove by hand. Lawson ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.
lawson_whitney(a)juno.com wrote:
Pity you couldn't use some other environment variable. The entire unix Yes, but make must also be able to find the tools, hence they are in the path (I am using Linux's binfmt_misc with the appropriate settings so that the programs are directly executable).
compiler would look in, say MYPATH, a shell script could easily set that how it liked. If I had the source, it would already be running natively. However, in this case I don't - the compiler is for a DSP, and is most definitely Closed Source....
*nix current directory is another possibility you should consider. If The project is a rather large one, comprised of over 9000 files in many different directories. Having the tools always in CWD isn't an option.
wineserver -p
Great! One down, one to go. I'll add that to the initial setup shell script. Perhaps, one fine day when I'm not trying to get a 160G drive to play nice in my computer, and I've taken the time to get ADPCM working in Wine, I can add some sort of additional path environment logic in. And **I** would actually rather release under LGPL, thankyouverymuch.
On Thu, 14 Feb 2002, David D. Hagood wrote:
The project is a rather large one, comprised of over 9000 files in many different directories. Having the tools always in CWD isn't an option.
Well, maybe I am stupid, but I don't see why you can't just install the tools somewhere, and add the windows path to that somewhere to Wine's "Path" = and be done with it. Unless the leafnames of the tools have different meanings depending where they are called from, and they are called only by leafname, that should about do it. You mentioned binfmt_misc, and GNU make, IIRC, so maybe what you miss is that you can always call an executable by absolute or relative pathname as well as by leafname; if called by leafname from *NIX, it will be searched for in the *NIX path, and the wine path doesn't matter. If it is not any other kind of executable, and binfmt_misc finds it to be a wine executable, it will call on wine to execute it, and IIRC it will give Wine the absolute path to find it by. What exactly is the problem? :-) Lawson Probable user head space error. - Dennis A. Moore
The problems with adding the code directly to the Wine config path are: 1) We package the tools along with the project - that way, if the tools are updated for a giving build, they will always be available with that build. I've done too much code archeology where I couldn't build a release because of subtle differences between tool versions, and I don't want to play that. 2) Our release procedure states that the developers are to make the code available to a software configuration control and management person, and they regenerate the project. The less configuration they have to do beforehand the better. 3) There can be multiple copies of the project checked out of CVS - I would like to be able to just do a "cvs co project; cd project; ./m" and have a build. Adding the tools to Wine's path will work, however it introduces a point of difference between running under CMD.EXE under Windows and running under Wine in that one way you can dynamically extend the path, one way you cannot.
On 2002.02.14 22:08 David D. Hagood wrote:
lawson_whitney(a)juno.com wrote:
Pity you couldn't use some other environment variable. The entire unix Yes, but make must also be able to find the tools, hence they are in the path (I am using Linux's binfmt_misc with the appropriate settings so that the programs are directly executable).
compiler would look in, say MYPATH, a shell script could easily set that how it liked. If I had the source, it would already be running natively. However, in this case I don't - the compiler is for a DSP, and is most definitely Closed Source....
*nix current directory is another possibility you should consider. If The project is a rather large one, comprised of over 9000 files in many different directories. Having the tools always in CWD isn't an option.
wineserver -p
Great! One down, one to go. I'll add that to the initial setup shell script.
Perhaps, one fine day when I'm not trying to get a 160G drive to play nice in my computer, and I've taken the time to get ADPCM working in Wine, I can add some sort of additional path environment logic in.
How about this: Wine reads your ~/.wine/config in as a registry file. When you start the wineserver you get the server started up. The first invocation of wine reads the config file into the registry. Thus the "Path" = "...." is actually stored in the registry and can thus be changed by using the regtool. Assuming upon startup of any program it reads the environment variables out of the registry and sets them from that, then you should be able to use the regtool to append the appropriate path from your script. Then when you run the compiler it will have the proper path. This is of course assuming that the wineserver remains persistent and thus further invocations of wine processes do not reread in the config file and overwrite what you have done to the path. I /think/ this will work.. no guarantee. Lemme know if it does.
And **I** would actually rather release under LGPL, thankyouverymuch.
-Dave
actually, I don't see a path specified in my wine config file, are you sure that's how it gets the unix path? and if it is stored in the config file, you could just use a pretty simple sed or perl script to insert it into the file. ----- Original Message ----- From: <lawson_whitney(a)juno.com> To: <wowbagger(a)sktc.net> Cc: <wine-devel(a)winehq.com> Sent: Thursday, February 14, 2002 6:25 PM Subject: Re: Wine's path VS host path
On Thu, 14 Feb 2002, David D. Hagood wrote:
Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine.
The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.).
Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is "self-contained". The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs.
Pity you couldn't use some other environment variable. The entire unix environment is available in the windows app's environment, but PATH is significant to windows apps, I guess, so wine takes the windified version of it from the config file to replace the *NIX value. If your compiler would look in, say MYPATH, a shell script could easily set that how it liked.
*nix current directory is another possibility you should consider. If it happens that it can be accessed somewhere on a Wine drive, Wine will use it as the windows current directory, which is on the windows path, I think, implicitly. If not it will use the windows directory and write a mesage to that effect.
As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path.
Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime?
On a related note: would it be possible to have a means to tell the wineserver process to "hang around" for a few seconds after the last wine process using it has terminated? Again, in this make process you get lots of "start wine, start compiler, compile, exit. Start wine, start compiler, compile, exit" operations - if the wineserver stuck around for 2 seconds after the last wine process terminated, this would aviod starting and stopping the wineserver process.
start
wineserver -p
before starting any compiles, it will serve until it is killed. kill it with -INT or -TERM, please, not -KILL. -KILL will force it to leave a stale socket you will have to remove by hand.
Lawson
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.
On Fri, 15 Feb 2002, Michael Cardenas wrote:
actually, I don't see a path specified in my wine config file, are you sure that's how it gets the unix path?
[wine] "Path" =
and if it is stored in the config file, you could just use a pretty simple sed or perl script to insert it into the file.
Err, yes, but he wants the wineserver to persist (to avouid the start/stop overhead), and it is the wineserver that reads $WINEPREFIX/config I think. Lawson It is better to be lucky than good. - J. A. Soucy --- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.
On Thu, Feb 14, 2002 at 06:17:56PM -0600, David D. Hagood wrote:
Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine.
The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.).
Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is "self-contained". The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs.
As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path.
Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime? My newly submitted patch "implement "App Paths" support" might just be what you need... (disclaimer: I did *not* implement it for you ! :-)
-- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/
Andreas Mohr wrote:
On Thu, Feb 14, 2002 at 06:17:56PM -0600, David D. Hagood wrote:
My newly submitted patch "implement "App Paths" support" might just be what you need... (disclaimer: I did *not* implement it for you ! :-)
I would never be so foolish as to expect someone to implement something just for me ;^> However, I know for a fact this app is only searching the path - under Windows it's possible to extract the project to any directory and start a build, and all I do is add it to the environment PATH, not a registry key.
participants (5)
-
Andreas Mohr -
David D. Hagood -
David Elliott -
lawson_whitney＠juno.com -
Michael Cardenas