Discussion on LKML

[joshudson]

Ended up like so:

>>>>> "Joshua" == Joshua Hudson <joshudson@gmail.com> writes:

Joshua> On 4/7/06, John Stoffel <john@stoffel.org> wrote:
>> >>>>> "Joshua" == Joshua Hudson <joshudson@gmail.com> writes:
>>
Joshua> Excellent point. This proposal needs to die, but there needs
Joshua> to be some way to solve this problem.
>>
>> Why don't you try to explain the problem in more depth, but without
>> assuming a solution at all. Just talk about what you're trying to
>> fix.
>>
>> As a SysAdmin by trade, if the program is written sanely, it's not
>> hard to make it relocateable and runable from anywhere. It's when the
>> program *knows* or the libraries is uses *know* that stuff is in
>> certain locations that things break.

Joshua> You mean as in it knows where its own data files live?

Like I said, if the program is written sanely.

Joshua> One example I am quite familiar with: game Battle for Wesnoth
Joshua> Installs binary into $PREFIX/bin
Joshua> Installs data files into $PREFIX/share/wesnoth
Joshua> Value of $PREFIX/share/wesnoth is hardcoded into binary

Stupid. It should be allowing the use of WESNOTH_LIB_PATH as an
environment variable so you could stuff the game where ever you want.
Heck, you've got the source, fix it and offer the patch back to the
admins.

Joshua> The problem: try compiling the game to run from a usb memory
Joshua> stick. You don't know the value of $PREFIX at compile time
Joshua> because that depends on where the memory stick is mounted.

You're missing the forest for the trees. Step back and look at how
other Unix like programs have solved this issue for years and years.
Sure, you code in a compile time $PREFIX, but you also allow it to be
over-ridden at run-time if need be. Nothing magic about it. Sorry
for the pun.

It certainly wouldn't take me that long to whip up a patch, all you'd
have to do is google to find some app which already does this and then
steal^H^H^H^H^Hre-implement the code to make it work the way they
want.

If the source wasn't 60+Mb, I'd do it myself.

Such a feature ($WESNOTH_LIB_DIR or such) already in wesnoth?
Should there be?

[sparr]

can $PREFIX be relative? can it be ".", then you make install from the USB drive and run the binary from the root of the USB drive?

[joshudson]

make install from the USB drive and run the binary from the root of the USB drive?

command to "make install" with cd != compile directory?
./configure && make should work with that however (assuming wesnoth doesn't use chdir() anywhere)

[Dave]

You can specify the path to Wesnoth's data files on the command line:

Code: Select all

wesnoth /path/to/data

I wouldn't be opposed to also allowing an environment variable, but that's a matter of taste. The problem is already solved as far as I'm concerned through this command line option.

(Personally I'm not that fond of every program having its own environment variables set, if it can be avoided -- I prefer things to be specified on the program's command line).

David

[jonadab]

(Personally I'm not that fond of every program having its own environment variables set, if it can be avoided -- I prefer things to be specified on the program's command line).

Agreed. What the people on LKLM were missing when they suggested environment variables is that Wesnoth is not *nix-only. Some of the platforms it wants to run on do not deal well with enormous quantities of environment variables; in particular, on Windows, it is considered Bad Behavior for an individual program (other than the command prompt) to need its own environment variables. Programs on Windows are supposed to use registry settings for this stuff. Registry settings are obviously not portable to _other_ platforms that Wesnoth runs on, so the command-line option is a good one that should work on both types of system. People who still think MacOS Classic is better than OS X will of course not agree, but unless there is a porting effort underway to get Wesnoth to run on that OS, I wouldn't lose sleep over that. Stick with the command-line option.

The existence of command-line options should, however, probably be better advertised.

[Soliton]

The existence of command-line options should, however, probably be better advertised.

Like in a man page or with a --help parameter?

[sparr]

one thing most people dont realize about environment variables is that they dont have to be exported. they can be specified for ONE application and then are discarded.

PATHTODATA=/usr/share/games/wesnoth wesnoth

this is the traditionally accepted way to accomplish such things.

[jonadab]

The existence of command-line options should, however, probably be better advertised.

Like in a man page or with a --help parameter?

Well, there too, but I was thinking more like here:
http://www.wesnoth.org/wiki/WesnothManual
Maybe even here:
http://www.wesnoth.org/wiki/GettingStarted

It isn't necessary to detail all the command-line parameters in those places, just to mention that there are some and maybe link to a page that details them.

one thing most people dont realize about environment variables is that they dont have to be exported. they can be specified for ONE application and then are discarded.

PATHTODATA=/usr/share/games/wesnoth wesnoth

this is the traditionally accepted way to accomplish such things.

This is a Unix-centric remark. I already said that environment variables are a perfectly reasonable interface in the POSIX world, but Wesnoth runs on more platforms than that. (Yes, it's technically possible to do something equivalent to the above on other platforms, but it can be rather a lot more of a hassle. Command-line options are a much more platform-neutral interface for this.)