Re: Announce: gio merged

[Hans Breuer <hans breuer org>]

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