Re: [fluid-dev] Role of glib

[David Henningsson]

address@hidden skrev:
> I've been somewhat avoiding the decision as to what extent glib will be
> used by FluidSynth.  

First; thanks for bringing it up. It is time to reach a decision here.

It also reminds me of another thought I had the other week. I think it
would be a good idea to lift the "porters" and give them more credit for
their work. A "porter", or "platform maintainer", would be officially
responsible for testing FluidSynth on that platform, maintain
source/binary packaging and build instructions. In return, they get
their names in the AUTHORS file and on the wiki, a feeling of doing
something great for the community, and ... ehm ... VIP tickets to the
next FluidSynth release party? ;-)

> Glib integration options:

Another option would be to skip glib and look for another library with
better platform support. But is there such a library?

> 1. Simply require glib.
> PROS: Least amount of work on the part of the developers.
> CONS: Extra dependency, not so straightforward to build on some
> platforms or not well supported (iPhone, OS/2).

The platforms we have are currently: Linux, Windows, OSX, OS/2 and
iPhone. MacOS9 support is dropped. Did I forget a platform?

> Option A:
> Alias all glib functions with FluidSynth equivalent macros.  So
> fluid_hashtable_t would just be an alias for GHashTable for example.
> 
> Option B:
> Start using glib functions and symbols directly, don't hide them behind
> FluidSynth renames.
> 
> Option A and B are independent of the 3 integration options.  I'm
> starting to like option B the best, since I don't see a need to hide
> glib functions and it just creates more work.

My vote goes for B. If glib is not used, porters could use macros to
make GHashTable an alias for their hashtable implementation. I see no
advantage whatsoever with A.

> There is a definite limit on the amount of development manpower that
> FluidSynth has.  I have many other projects which are also in need of
> attention, so I'm of the mind that the easier it is for me to move in a
> forward direction with FluidSynth the better.  There is a trade off
> though, in regards to keeping FluidSynth simple and standalone with
> minimal or no required dependencies and making development easier.

Everybody scratches their itches - could the OS/2 and iPhone porter
maintain a stripped glib on that platform?

> A lot of this headache is probably due to autohell and company
> (autoconf/automake/etc).  

I'm not really following what glib has to do with autotools...? Does it
use autotools to build?
Although I wouldn't mind having another build system as well. As long as
it doesn't mean a lot more to maintain.

> One additional thought, is to provide a build time option which requires
> no additional dependencies and builds a simpler, possibly single
> threaded, libfluidsynth, meant for the embedded case.  This would
> complicate development somewhat, but would probably cover many of the
> use cases where the glib dependency is a problem.

Sometimes I have thought that the FluidSynth library should be split
into two, one "core rendering" synth with minimal dependencies, and one
with all dependencies (Audio drivers, midi drivers, LASH, readline,
etc). The reasoning behind this is that distributions like Debian build
FluidSynth with support for everything. And applications that has their
own driver support (VLC, fluidsynth-dssi, etc) then wouldn't have
unnecessary dependencies.

That was probably a parenthesis but perhaps something to consider for 2.0.

> Can anyone offer some words of wisdom?

Sure. I just surfed into qotd.org and they presented the following word
of wisdom just for us:

"A new vision of development is emerging. Development is becoming a
people-centered process, whose ultimate goal must be the improvement of
the human condition. - Boutros Boutros-Ghali (b. 1922), Egyptian
government official, diplomat"

:-)

// David