Re: [AD] 5.0.0 final release plan

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On January 4, 2011, Peter Wang wrote:
> On 2011-01-04, Matthew Leverton <meffer@xxxxxxxxxx> 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.
> 
> Nearly all Allegro programs I will run in-place, never installing.
> BUNDLED_DATA works then.
> 
> It is also pretty common nowadays (if not great form) for application
> programs, especially games, to keep all their data in a single
> directory, with only a symlink or shell script in /usr/bin. 

Or at least in $PATH. I have a ~/bin and ~/sbin that I'll place links to 
programs I've installed locally.

> For
> BUNDLED_DATA, a shell script would be required (unless we resolve the
> symlink, which seems like it might cause confusion).

Hmm. I'm not sure how to handle that. for EXENAME we shouldn't probably 
resolve any symlink, but for BUNDLED_DATA, probably should. That would be the 
only way to get at the actual data dir.

> > 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
> 
> Sounds fine to me.
> 
> Peter
> 
> ---------------------------------------------------------------------------
> --- 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