Re: [AD] al_set_win_dll_path

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Wed, Jul 27, 2011 at 5:13 AM, Elias Pschernig
<elias.pschernig@xxxxxxxxxx> wrote:
> al_set_standard_path(int id, ALLEGRO_PATH *path)?
>
I thought about recommending that before when we had the long
discussions. Maybe I did, I dunno.

It's probably only useful with ALLEGRO_RESOURCES_PATH, but ultimately
I think I decided that the programmer might as well just create a
wrapper function like get_path() around ALLEGRO_RESOURCES_PATH and his
own UNIX_CONFIGURE_DATA_PATH compile time option.

Anyway, all that is kind of a side topic. But maybe there is something here.

There could be something like ALLEGRO_LIBRARY_PATH that is writable,
but you'd almost have to then add support for multiple paths for a
single id, via al_get_nth_standard_path(int id, int n).

I think I would prefer the following:

* roll back the change to Windows that prevents DLL hijacking. Does it
really matter?

* set the PATH/LD_LIBRARY_PATH environment variable yourself, and let
Allegro automatically pick that up.

If you don't want to disable the DLL hijack completely, you could do
something like:

c = al_get_system_config();
al_set_config_value(c, "windows", "use_sys_path_for_dlls", "1");

And failing that suggestion:

c = al_get_system_config();
al_set_config_value(c, "path", "library", "c:/foo/bar");

And failing that suggestion:

al_set_plugin_search_path(ALLEGRO_PATH *path)


It's just that to me, this seems like a very edge case (getting python
to work on Windows) and generally we don't want to encourage people to
muck with these types of settings with code, when the OS provides a
natural way for the user to override things.

--
Matthew Leverton