Re: gio on win32 (was Re: Announce: gio merged)

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-12-05 at 22:13 +0100, Hans Breuer wrote:
> On 05.12.2007 12:19, Alexander Larsson wrote:
> > On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote:
> >> On 03.12.2007 10:07, Alexander Larsson wrote:
> > 
> >>> Thats a way it can be made to work with the current use in libgio, but
> >>> it makes the API sort of weird for win32. How exactly is the dynamic
> >>> path calculated? Maybe its possible to make the API work in some
> >>> relative way? That way some other library on could also use
> >>> g_io_modules_ensure_loaded() to load its modules relative to its dll.
> >>>
> >> The thing needed than would be the DLL name or the HANDLE of the DLL to
> >> resolve the relative path against. I'm not sure though how the
> >> responsibilities need to be split for loading some gio-modules.
> >> Is an application supposed to deliver it's own extension modules for gio?
> > 
> > I changed this so that _g_io_modules_ensure_loaded is a private function
> > that only glib uses for its libs. It takes no arguments and could use
> > whatever magic require on win32 to find the module directory.
> > 
> > Instead I exported g_io_modules_load_all_in_directory, which is used in
> > the implementation of _g_io_modules_ensure_loaded. It can be used in
> > other libraries (such as in gvfs) to implement a similar thing.
> > 
> > Is this ok for you?
> > 
> Looks good. So I guess someone needs to write the first gio-module working
> on windoze - maybe around FindFirstChangeNotification() ;)

I don't think that needs to be a module actually. I've made the fam file
monitor a module, so that gio doesn't link to libfam. However, the
inotify monitor is built in, as that has no extra dependencies. (Loading
modules is not free, as it causes an extra private dirty page.)