[Top][All Lists]

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

Re: [fluid-dev] glib changes checked in

From: Pedro Lopez-Cabanillas
Subject: Re: [fluid-dev] glib changes checked in
Date: Fri, 1 May 2009 21:26:37 +0200
User-agent: KMail/1.9.6 (enterprise 20070904.708012)

On Monday, April 27, 2009, address@hidden wrote:
> I just checked in some initial changes which make glib 2.10+ a
> dependency for FluidSynth, cleans up a lot of platform specific code
> in favor of glib provided functions and adds initial support for WIN32
> TCP server support (not yet tested).
> Change overview:
> - Moved code in fluid_io.[ch] to fluid_sys.[ch] and added WIN32
> support, removed fluid_io.[ch]
> - fluid_utime() and fluid_curtime() now use glib
> - fluid_thread implementation now uses glib
> - mutexes now using glib
> - removed a bit of code in fluid_defsfont.h which had originally been
> ripped from glib
> - WIN32 support for fluid_socket related code
> For the moment I have just kept the FluidSynth named macros/functions,
> defined them as aliases, rather than replace every usage of them with
> the glib equivalents.  We may or may not want to do that in the future.
> The WIN32 TCP server support code was not tested and I'm not even sure
> it will build.  If someone could test this that would be great.  The
> WITHOUT_SERVER option should be removed from src/config_win32.h to try
> the server code.  There might be other stray #ifdef WIN32 directives
> that still need to be removed though.  Building with glib will be an
> additional requirement which needs to be sorted out.

Builds now with msys/mingw32, with a little change to configure.ac (required 
to link against winsock), but I've not tried yet with MSVC.

The executable doesn't work, though: it aborts abruptly after the greeting, 
without clues.

> Some notes on using glib:
> Replace code which verifies function inputs with g_return_if_fail and
> g_return_val_if_fail (i.e., programming errors)
> We should probably avoid using glib memory allocation functions,
> especially when allocating lots of memory, since they terminate the
> application instead of returning NULL
> Testing and feedback welcome!
>      Josh

What about fluid_hash.* and fluid_list.* ?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]