Re: g_module_build_path on Win32

[Rick Jones <rick jones2 hp com>]

Tor Lillqvist wrote:
> Rick Jones writes:
>  > http://developer.gnome.org/doc/API/2.0/glib/glib-Dynamic-Loading-of-Modules.html#g-module-build-path
>  > which reads:
>  > 
>  >    For example, calling g_module_build_path() on a Linux system with a
>  >    directory of /lib and a module_name of "mylibrary" will return
>  >    /lib/libmylibrary.so. On a Windows system, using \Windows as the
>  >    directory it will return \Windows\mylibrary.dll.
>
> A documentation bug! Thanks for reporting.

if there is one thing I've become skilled at, it is picking document nits :)

>  > Might be good to flesh-out the examples a bit and explain the whole thing.
>
>  > Since g_module_open knows how to deal with .la files, should 
>  > g_module_build_path() special case seeing a .la at the end of the 
>  > module_name?
>
> Probably yes.
>
> But really, the g_module_build_path() function is IMHO not that
> awfully useful.

I kept thinking it was trying to build a path string a la Path/PATH :)

> What would be more useful would perhaps be was a function like
>
>   g_module_open_from_directory(const char  *directory,
>                                const char  *module,
>                                GModuleFlags flags)
>
> which on Windows would actually try both with and without the "lib"
> prefix. Or maybe the existing g_module_open() should just be extended
> to do that, i.e. even if you pass it x:\foobar\zap.dll it would also
> try x:\foobar\libzap.dll if zap.dll wasn't found. (cygzap.dll on
> Cygwin)

if we are going to go that far why not replace directory with a path string?

rick jones

> --tml