Dmitry Timoshkov dmitry@baikal.ru writes:
Define WINEPREFIX if it doesn't exist.
Why do you need that?
"Alexandre Julliard" julliard@winehq.org wrote:
Define WINEPREFIX if it doesn't exist.Why do you need that?
I have several Wine trees locally, and start up scripts some of them set WINEPREFIX to a non default value. In order to avoid setting it in my ~/.profile I'd prefer that each Wine start up script sets this either to each own unique value or, if it has no special preferences, set it to the default one.
"Dmitry Timoshkov" dmitry@baikal.ru writes:
I have several Wine trees locally, and start up scripts some of them set WINEPREFIX to a non default value. In order to avoid setting it in my ~/.profile I'd prefer that each Wine start up script sets this either to each own unique value or, if it has no special preferences, set it to the default one.
I still don't see why you want that, if it's not set Wine will use the default one already.
"Alexandre Julliard" julliard@winehq.org wrote:
I still don't see why you want that, if it's not set Wine will use the default one already.
Why does wineps complain that it couldn't load "%WINEPREFIX%/generic.ppd" specified in the config in the case WINEPREFIX is not set in my environment?
"Dmitry Timoshkov" dmitry@baikal.ru writes:
Why does wineps complain that it couldn't load "%WINEPREFIX%/generic.ppd" specified in the config in the case WINEPREFIX is not set in my environment?
Because WINEPREFIX is not set of course. The solution is not to set it unconditionally, but to fix your config and/or wineps to do the right thing when WINEPREFIX is not set.
"Alexandre Julliard" julliard@winehq.org wrote:
Because WINEPREFIX is not set of course. The solution is not to set it unconditionally, but to fix your config and/or wineps to do the right thing when WINEPREFIX is not set.
I'm not sure what do you mean by "the right thing" here. Do you mean that I'm not allowed to use WINEPREFIX in the config, or you mean that every single dll should have its own ExpandEnvironmentStrings implementation? Something else?
"Dmitry Timoshkov" dmitry@baikal.ru writes:
I'm not sure what do you mean by "the right thing" here. Do you mean that I'm not allowed to use WINEPREFIX in the config, or you mean that every single dll should have its own ExpandEnvironmentStrings implementation? Something else?
Well, you cannot use WINEPREFIX in the config file that is in ~/.wine/config, since it can potentially be used without the prefix being set. The easiest is to replace %WINEPREFIX% by %HOME%/.wine in that specific config file.
A more elaborate solution would be to make wineps look in the prefix dir when it gets a relative dir, like the drive config code does. I'm not convinced we want to do that though, IMO it would be better to install generic.ppd globally and make wineps default to something like $(libdir)/generic.ppd.
"Alexandre Julliard" julliard@winehq.org wrote:
Well, you cannot use WINEPREFIX in the config file that is in ~/.wine/config, since it can potentially be used without the prefix being set. The easiest is to replace %WINEPREFIX% by %HOME%/.wine in that specific config file.
But in order to read ~/.wine/config WINEPREFIX should be either already detected or any default value used. Why not use that value everywhere else? After all, what is the problem with using a default value, which actually is being already used?
A more elaborate solution would be to make wineps look in the prefix dir when it gets a relative dir, like the drive config code does. I'm not convinced we want to do that though, IMO it would be better to install generic.ppd globally and make wineps default to something like $(libdir)/generic.ppd.
But that would effectively invalidate all the efforts to make Wine easily configurable. There are situations when somebody wants by changing single environment variable get completely different Wine environment: with distinct registry, config, win.ini, .ppd and other files...
Again, what is the problem with using a default value in the case it wasn't set? It works for config itself, why it can't work for anything else?
"Dmitry Timoshkov" dmitry@baikal.ru writes:
But in order to read ~/.wine/config WINEPREFIX should be either already detected or any default value used. Why not use that value everywhere else? After all, what is the problem with using a default value, which actually is being already used?
The problem is that you can't depend on it being set, because Wine is supposed to work fine without it. Setting it in the wrapper script won't change that, because the wrapper is only used when running from inside the source tree.
But that would effectively invalidate all the efforts to make Wine easily configurable. There are situations when somebody wants by changing single environment variable get completely different Wine environment: with distinct registry, config, win.ini, .ppd and other files...
On the contrary, it's even easier to configure if you don't have to install generic.ppd at all and it just uses the global one. You could still specify it in the config file if you really wanted, but you shouldn't have to. Of course if you want multiple Wine environments with different generic.ppd files then you need to tweak the config; but that's definitely not the standard case.
"Alexandre Julliard" julliard@winehq.org wrote:
The problem is that you can't depend on it being set, because Wine is supposed to work fine without it. Setting it in the wrapper script won't change that, because the wrapper is only used when running from inside the source tree.
How about the following solution: do not set WINEPREFIX in the startup script, just add it to the Wine environment (possibly even not propagating it to the Unix environment) in the case it wasn't already set?
"Dmitry Timoshkov" dmitry@baikal.ru writes:
How about the following solution: do not set WINEPREFIX in the startup script, just add it to the Wine environment (possibly even not propagating it to the Unix environment) in the case it wasn't already set?
I don't think we want to modify the environment unless really necessary, and IMO it's not necessary in that case.
-
Alexandre Julliard -
Dmitry Timoshkov