Re: [AD] standard path updates

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Wed, Mar 2, 2011 at 9:05 AM, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> No, but aren't we overthinking this in a sense?
> Couldn't we simply return whatever the appropriate value for ProgramData is and leave it up to the user to assemble a complete path from that?
>
First off, I don't think we should modify the RESOURCE folder at all.
I think it serves its purpose just fine. (Locating bundled data.) So
I'll assume we are discussing a SYSTEM_DATA folder that represents
some sort of read-only application level location based on some sort
of common system setting.

A big problem right from the start is that on Linux, people are going
to want a choice. During development, they use the relative location
(RESOURCE). But when the game goes into distribution, the data could
perhaps go anywhere. Maybe as a zip file, it's bundled with the
program. Maybe as an official RPM it gets put into /usr/share. Maybe
as a ./configure option, it gets put into /usr/local/share.

There's no way for Allegro to autodetect that behavior. And are we
prepared to force people to use /usr/share (or /usr/local/share). What
would happen? People would end up writing their own special #ifdef for
Linux to support their favorite place to put resource data on install.
i.e., the SYSTEM_DATA location would still be useless for them.

Peter says symlinks are resolving. Personally, I think that's the most
straightforward way to solve the problem: make it known that if you
want the exe to be /usr/bin/game, then it needs to be a symlink to
/usr/share/gamedata/game.

It requires no extra code, and everything remains cross platform.

On Windows, people who use an installer can bundled their data with
their exe in program files. There's no need for them to support
programdata.

On OS X, the RESOURCE location easily serves both purposes due to the
well defined nature of bundles.

To me, it's problem solved. (Maybe update the docs to explain this a
bit better.)

I think your comment about putting this into the physfs addion is
something to consider. There could be a function you could call that
would add *all* system data locations to the search path using the
$appname as a helper. All XDG folders could be added by priority, etc.
The programmer could #ifdef a ./configure supplied location in there
and add it to the search list if needed.

> I don't think EXENAME is all that useful anyway though...
>
Me neither (unless you embedded data into it), and perhaps it's
already resolving anyway. I don't really have a strong opinion on
that.

--
Matthew Leverton