Re: [AD] search path?

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

Thomas Fjellstrom wrote:
> On Tue April 14 2009, Peter Wang wrote:
> > What was the motivation for the search path stuff, i.e.
> > al_add_search_path, etc.?
> >
> > I don't see any reason to keep it.  It's likely a source of confusion as
> > most people passing a relative filename will expect it to be opened
> > relative to the current directory only, not relative to some set of
> > directories.  And when you consider opening files for writing...
>
> Its been asked for many times. I personally think its useful, and physfs uses
> it to find paths and to tell it to use archives as paths as well. With a 
> physfs addon, you'd access files in archives like so:
>
> al_add_search_path("archive.zip"); // contains music and images folders
> ALLEGRO_FS_ENTRY *game_opening = al_fopen("music/game_opening.ogg");
> // or alternatively
> al_load_sound("music/game_opening.ogg"); // if the acodec ogg code uses 
> allegro's fshooks properly, it'll find it in the zip file
>
> And it is quite convenient to use without archives.

I just looked at physfs, they also allow setting a (single) write path which is 
used instead of this when writing. So if we want it, we also need a way to set 
the write path. And we also need to do something akin to their 
permitSymbolicLinks function.

http://icculus.org/physfs/docs/html/physfs_8h.html

However, I think this is too confusing, with little benefit. The code intense 
part here is constructing the directories using al_get_standard_path(). So, all 
this function does is, instead of calling al_fopen for each of your paths, you 
now pass each path to al_add_search_path first, then call al_fopen. It seems 
mostly pointless - a simple wrapper function has just the same effect.

--
Elias Pschernig <elias@xxxxxxxxxx>