Re: [AD] al_set_win_dll_path

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Mon, Jul 25, 2011 at 4:43 PM, Elias Pschernig
<elias.pschernig@xxxxxxxxxx> wrote:
> Well, the problem really is that Allegro right now hardcodes the DLL
> path to be in the same folder as the .exe. In my case that's the
> system-wide python.exe so its location has nothing at all to do with
> where my game has libvorbis.dll.
>
A manifest won't help here, because it'd have to be embedded in
python.exe or named python.manfest next to python.exe (I think).

I'm just sort of against platform specific functions as a matter of
principle when they can be avoided. (e.g., Many of the iphone ones, to
me, could easily be platform ones. Things like al_get_battery_level()
could apply to a laptop, etc.)

Another way to resolve this would be something like:

al_register_library_loader(proc /* user written callback */);
al_unregister_library_loader(proc);

bool proc(const char *name, char *folder, int len)
{
  // name [in] => name of file being loaded. could be used to
determine which folder is relevant
  // folder [out] => place to find library
  // len [in] => folder buffer size

  strcpy(folder, "c:/myfolder");

  return true; /* use this folder */
}

Any time Allegro needs to load a library, it would use the first
folder set by a proc that returned true.

Not sure if this type of thing applies to Linux / OS X as well, but
the above could solve it for all platforms. But if this is only ever a
Windows problem, then the above is just over engineering.

--
Matthew Leverton