Re: [AD] standard path updates

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Mon, Feb 28, 2011 at 3:44 AM, Thomas Fjellstrom
<tfjellstrom@xxxxxxxxxx> wrote:
> I should have tested better. RESOURCES_PATH is incorrect, at least when the
> binary is installed in a system dir.
>
> It decides to give:
>
> RESOURCES_PATH: /usr/local/bin/
>
Per the previous discussion and as documented in the manual, the
behavior is correct:

"If you bundle data in a location relative to your executable, then
you should use this path to locate that data. ... If you install your
resources in some other system directory (e.g., in /usr/share or
C:\ProgramData), then you are responsible for keeping track of that
yourself."

> It should probably give something in $XDG_DATA_DIRS, which one to pick is
> probably a bit hard... maybe which ever one contains the org_name/app_name
> dir?
>
This is precisely why we ultimately decided not to support system
directories in 5.0: it's a mess to figure out in a cross platform way
that is reliable. Basically, if you choose to install your data via
some "installer" methodology (e.g., ./configure or Install Shield),
then you're on your own to keep track of that.

In order to properly support it, we would need to have a function like:

al_set_resource_directory(const char *directory);

The programmer would have to call that function:

#ifdef LINUX
al_set_resource_directory(DIR_FROM_CONFIGURE);
#endif

#ifdef WINDOWS
al_set_resource_directory("c:/programdata/myapp/");
#endif

But if the programmer has to do that, then there's not much reason to
even use the standard path functions.

--
Matthew Leverton