Re: [AD] 5.0.0 final release plan

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On January 4, 2011, Matthew Leverton wrote:
> On Tue, Jan 4, 2011 at 7:03 AM, Peter Hull <peterhull90@xxxxxxxxxx> wrote:
> > OSX has an API to get these locations (as used in the current code)
> > 
> > Would it be possible under linux to detect if an exe is 'installed'
> > and look in the corresponding place and if not look relative to the
> > exe
> 
> I think all of us participating in this discussion are basically in
> agreement for 5.0 to just not include any paths that represent shared
> (writable) or installed (readable) data. I don't think it's something
> we should rush to fit in, because given that they aren't that useful
> to the average Allegro app, it's worse to implement them incorrectly
> than to not do them at all.
> 
> In 5.0, if somebody wants to write a cross platform way to handle
> installed data, then they can just do this in their code:
> --
> string get_etc_path(string path)
> {
> #ifdef LINUX
>   return ETC_PATH + path;
> #else
>   return al_get_standard_path(ALLEGRO_BUNDLED_DATA_PATH) + path;
> #endif
> }
> al_open_config(get_etc_path("foo.ini"));
> --
> 
> Psuedo-code, obviously. The point is, under LInux, they could hard
> code some ETC_PATH during the build process. On OS X and Windows, they
> could just use some bundled data path. Or whatever... The main thing
> is that it's hard for Allegro to actually support this correctly
> without mandating that you install things in a certain location.
> Otherwise, you'd either have to set an ETC_PATH of sorts during the
> build process, or set an APP_NAME and ORG_NAME at compile time that
> reflects where the program was installed. But I think it's simpler to
> just do nothing.

One little nit pick, you should always set appname and orgname. Though I 
suppose we could do without orgname. But I think it keeps things a little 
cleaner if things are separated like that.

> The previous message I sent with three numbered things to do is
> 
> sufficient to address the current problems:
> >> 1) Rename PROGRAM_PATH to BUNDLED_DATA, and on OS X, dynamically
> >> detect if in an app bundle, and adjust accordingly.
> >> 2) Remove SYSTEM_DATA_PATH and SYSTEM_SETTINGS_PATH.
> >> 3) Make USER_HOME consistent, and add USER_DOCUMENTS
> > 
> > What's the difference between 'settings' and 'data'? (Sorry if I missed
> > it earlier)
> 
> In Linux terms, I think settings is /etc and data is /usr/share.
> 
> --
> Matthew Leverton
> 
> ---------------------------------------------------------------------------
> --- Learn how Oracle Real Application Clusters (RAC) One Node allows
> customers to consolidate database storage, standardize their database
> environment, and, should the need arise, upgrade to a full multi-node
> Oracle RAC database without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/