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

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

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).
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.

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?

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().

Evert