Re: [AD] SF.net SVN: alleg:[13892] allegro/branches/4.9/src/macosx/system.m

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Fri, 2010-11-12 at 18:59 -0500, Evert Glebbeek wrote:
> On 12 Nov 2010, at 11:31 , eglebbk@xxxxxxxxxx wrote:
> > Revision: 13892
> >          http://alleg.svn.sourceforge.net/alleg/?rev=13892&view=rev
> > Author:   eglebbk
> > Date:     2010-11-12 16:31:08 +0000 (Fri, 12 Nov 2010)
> > 
> > Log Message:
> > -----------
> > Correctly return standard paths as directories on OS X.
> 
> Actually, I may have been a bit rash with this patch. Not all of those
> should be directories, so I'll go and fix that later tonight (within
> the next few hours).
> However, that does raise another "how does this work on other
> platforms" question.
> On OS X, for instance, ALLEGRO_SYSTEM_SETTINGS_PATH returns
> "/Library/Application Support/appname", which would normally be a
> directory in which the application is expected to keep whatever
> configuration and optional stuff that doesn't go in the budle but is
> to be shared with all users. This is what prompted me to make the
> change (al_create_path -> al_create_path_for_directory) in the first
> place (this was always what it was intended to be).

In unix this is used. So the end result is a directory, something like
"/etc/org_name/app_name/". It might be clearer to use
al_create_path_for_directory for the "/etc/" entry and not rely on the
trailing slash.

         sys_path = al_create_path("/etc/");
         al_append_path_component(sys_path, al_get_org_name());
         al_append_path_component(sys_path, al_get_app_name());

> However, in the UNIX part al_create_path is also used, and a quick
> look at the code there suggests that the intended behaviour there is
> to return the path to a configuration file rather than a directory.

No, I doubt that. ALLEGRO_SYSTEM_SETTINGS_PATH is a read-only location
though as the above shows - we need to mention that in the docs.

> So, first question: is this correct? If not, then the UNIX port will
> need to be fixed in the same way as the OS X port.
> Second question: what is the "correct" (expected) return value on
> other platforms?
> Third question: assuming that there's a difference in terms of whether
> a particular system path points to a file or a directory depending on
> the platform (which I suspect), what's the best way to handle this?

I'm for always using directories (except the .exe).

> Or, if we go by the current documentation, then all of the
> ALLEGRO_*_PATH ids should correspond to a directory rather than a file
> (with the exception of ALLEGRO_EXENAME_PATH) in which case the UNIX
> and Windows ports should be checked for using
> al_create_path_for_directory() rather than al_create_path().
> 

Running ex_get_path displays this here:

PROGRAM_PATH: /home/elias/prog/allegro/git/build/examples/
TEMP_PATH: /tmp/
SYSTEM_DATA_PATH: /usr/share/liballeg.org/ex_get_path/
SYSTEM_SETTINGS_PATH: /etc/liballeg.org/ex_get_path/
USER_DATA_PATH: /home/elias/.config/liballeg.org/ex_get_path/
USER_SETTINGS_PATH: /home/elias/.config/liballeg.org/ex_get_path/
USER_HOME_PATH: /home/elias/
EXENAME_PATH: /home/elias/prog/allegro/git/build/examples/ex_get_path

The documentation could be improved a lot in any case, besides
mentioning that SYSTEM_DATA_PATH, SYSTEM_SETTINGS_PATH and PROGRAM_PATH
should be considered read-only (the last one being read-only in Windows
caused me a lot of trouble once) we might also show an example paths for
all supported platforms for each.

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>