fluid-dev
[Top][All Lists]
Advanced

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

[fluid-dev] Role of glib


From: josh
Subject: [fluid-dev] Role of glib
Date: Wed, 26 Aug 2009 02:50:14 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

I've been somewhat avoiding the decision as to what extent glib will be used by FluidSynth. After attempting to use fluid_hash.c to create a hash using an integer as a key, something very easily done with glib, I found that it wasn't simply a rename of the glib hash code and had been limited to string keys only.

I'm posting to the list to try and collect my own thoughts and get feedback, to help make the right decisions.

Glib integration options:

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

2. Glib optional, package a stripped down version of glib with FluidSynth.
PROS: Easier to build on systems without glib, use latest glib if available on system. CONS: Work required to strip down glib and possible long term maintenance needed. Still need to deal with how to build glib code on other OSes with different build environments.

3. Glib optional, package entire glib copy.
PROS: Perhaps slightly easier to build on other OSes, use latest glib if available on system. Less work needed in glib integration. CONS: Minimal benefit in build convenience, why not just build glib separately?

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.

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.

In a perfect world, just requiring glib would be the easiest for me. Though this extra dependency, although small, might be enough to cause FluidSynth to be less convenient to build and use in other environments. One of the main attractions of FluidSynth has been its ability to be easily embedded and used in other applications. While glib is very much an integral part of Linux systems, its not so readily available in other environments. So the main question is, how can we leverage glib and still provide some amount of convenience and simplicity to those using some of those other inferior OSes ;)

A lot of this headache is probably due to autohell and company (autoconf/automake/etc). So I'm not adverse to using another build system. I have not yet been very impressed with other build systems though, but perhaps I need to be shown that something else is better. I'm not real keen on stripping down glib and including it with FluidSynth and have doubts that it would necessarily make things easier anyways. Perhaps providing library binaries for Windows and including glib headers would help, since glib would not then not need to be built.

So. I currently like 1B. But I don't want that to reduce the usage scope of FluidSynth and so I'm willing to put in some effort to get things running smoothly in other environments.

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.

Can anyone offer some words of wisdom?

Josh Green





reply via email to

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