I am not a developer, so I might
be wrong on this, but perhaps the best solution would be to move to
glib, and if someone wants to use FluidSynth on a platform not
supported by glib, they could use an older version (1.0.9).
-~Chris
address@hidden wrote:
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
_______________________________________________
fluid-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/fluid-dev
|