Re: Announce: gio merged

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"
So at least now I know why it was not installed on my computer :-)

To be continued ...

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]