Re: Announce: gio merged



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.

> 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?

> 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.

> 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.



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