On 28.11.2007 09:24, Alexander Larsson wrote: > On Tue, 2007-11-27 at 22:34 +0100, Hans Breuer wrote: >> On 26.11.2007 17:25, Alexander Larsson wrote: >>> I just commited gio to the glib svn module. As this is a sort of large >>> chunk of work I expect there to be some temporary issues to work out. >>> >>> For instance, its likely that there are some build issues for platforms >>> I haven't tested. I got a bunch of solaris fixes for gio-standalone, >>> which hopefully survived the merge, but there might still be issues. >>> >>> I'd also like some help from the win32 folks to make sure this builds in >>> all the right ways. >>> >> Here comes the first chunk ;-) >> >> * gio/gcontenttype.c : use GDir instead of using <dirent.h> > > Hmm? Why is that building on Win32? It should be picking the #ifdef > G_OS_WIN32 part of that file. > You are right. I was just fooled by the unconditional #include <dirent.h> and mechanically translating to GDir (without testing if it compiles). But - given that there are two completely independent implementations in this file - wouldn't it be better to split it into gcontenttype-win32.c and gcontenttype-unix.c ?
>> gsocketinputstream.c gsocketoutputstream.c >> needs some reimplementation/porting to use winsock specific API. > > This has been made Unix only. We'll probably need a winsock version of > this later though. > >> g_io_modules_ensure_loaded (GIO_MODULE_DIR); >> It would be nice if this function would take no parameter to allow >> implementation of dynamic DLL placement resolvement in one place. > > Hmm. This is also used by gvfs to load its modules. It then passes a > different location to the function ($(libdir)/gvfs/modules). Can you > describe in more detail what you want it to do? > On windows the location of DLLs is deduce at runtime. It depends on where a setup installed the DLLs, rather than fixed at compiled time. Thus we have established a pattern to resolve module placement from the DLL loading them. See for example gtk/gtkmodules.c. My first idea was taht the parameter to g_io_modules_ensure_loaded() was always the same. Thus it would have been possible to do the dynamic path calcualtion in just this one function. Of course GIO_MODULE_DIR can be defined to a function call on win32, to keep the other code like it is. _gio_win32_module_dir() will have to return a static string than. >> glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test > > g_file_test is pretty lame though. It does a new stat each time you call it > and there are no ways to get more than a single piece of info for each call. > This will just slaughter i/o performance. > > What exactly is it that you need it to do that g_file_test does? We need to > move that into glocalfile.c instead. > The first thing is the undefined statfs_buffer for !USE_STATFS and !USE_STATVFS in g_local_file_query_filesystem_info. I need to understand the unknown API first to propose how to port it. On a quick glance the missing definition for S_ISDIR led me to propose g_file_test(). But of course this can be resolved differntly. >> Finally gio.symbols should be added to make exporting of symbols (and what >> not;) as easy as for glib/gobject and gtk+ > > It also needs to set up the aliases work for unix... I'll take a look at it. > >> Do you want me to commit the uncritical pieces? > > Everything but the gcontenttype.c part (that should not build on win32) > looks good to me. > Ok, revert that thing and just moved the #include <dirent.h> stuff into the !G_OS_WIN32 #else. In the first chunck I was also completely missing the gwin32appinfo.c thing. Now it is giving me a hard time by using somewhat unusual API - not available in my current Platform SDK installation. There are people claiming shlwapi.h to be "one of the worst designed libraries to come out of the Windows team" [http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=203814&SiteID=1] So at least now I know why it was not installed on my computer :-) To be continued ... Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list