Indeed, the platform maintainers deserve much credit! We should start by officially appointing the positions.
Ebrahim Mayat has been from the beginning the OS X maintainer.
As for Windows, there have been contributions from many individuals, but I don't think we have ever officially knighted a Windows maintainer. Antoine Schmitt? Pedro Lopez-Cabanillas?
KO Myung-Hun contributed the OS/2 support code, so he definitely deserves the title of OS/2 maintainer.
Looking at the AUTHORS file, I don't see David Henningsson listed at all! You should definitely put your name prominently in the development team list.
Where should we have the FluidSynth release party? ;)
Well summer's nearly over so I suggest "FluidSynth Live at the Fillmore - Spring 2010" or maybe "Coming soon to a theater near you" ;-)
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?
Glib is what I'm familiar with and is therefore the most convenient. I'm not aware of other C utility libraries that are as functional and portable as it. The problem platforms are OS/2 (latest build that I have seen is 2.6.5, which seems OK, but would add some limitations on using newer functions). iPhone doesn't support shared libraries at all, from what I have heard. So that means that FluidSynth and glib would have to be copy pasted into another application, which would therefore also have to be LGPL. 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?
Solaris and BSD variants. I don't think we really support iPhone at this point, though it is possible to get things working it seems. 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.
Sounds good.
Having just read the recent "Fluidsynth event queue and thread safety changes" thread, I have some basic questions:
I am under the impression that the adoption of glib would be beneficial to addressing issues of thread safety ? So, the numerous utility functions in GLib (or glib) would make for easier organization and integration of fluidsynth's data structures and objects into one thread ? If both my presumptions are true, then which specific glib routines would you consider for implementation ? 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?
Both glib (version 1.2.10) and glib2 (version 2.20.4) exist in the fink repository. So, which "glib" are you guys talking about?
Concerning the iPhone, the first thought that occurred to me was that one could simply compile and install glib* from source on the iPhone OS ?
I have not yet ventured into this area but perhaps Antoine could clarify our thoughts on this issue. That would alleviate some of the headache for us, that is for sure :) 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.
Following an excerpt from the fink compile script for glib....
ConfigureParams: --infodir=%p/share/info --mandir=%p/share/man --disable-static
CompileScript: <<
./configure %c
perl -pi.bak -e 's/HAVE_GETPWUID_R/HAVE_NOTHING_IMPORTANT/g' config.h
make SetCFLAGS: -Os
ConfigureParams: --mandir=%p/share/man --disable-gtk-doc --disable-dependency-tracking --disable-fam
CompileScript: <<
PERL_PATH=/usr/bin/perl PERL=/usr/bin/perl ./configure %c PYTHON=/usr/bin/python
perl -pi -e '$_="#define BROKEN_POLL 1\n" if /BROKEN_POLL/' config.h
make
<<
InfoTest: <<
TestDepends: <<
desktop-file-utils (>= 0.15-1),
shared-mime-info (>= 0.51-1)
<<
TestScript: LANG=C make check
<<
InstallScript: <<
make install DESTDIR=%d
mkdir -p %i/share/doc/installed-packages
touch %i/share/doc/installed-packages/%N So, yes autotools can be used to build glib and glib2. I was referring to the glib build process being autotools, which isn't very convenient on some platforms like Windows. Just using a pre-built library would make that easy though. 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.
I think this might be the way to resolve the embeddable issue too. If we can keep the FluidSynth synthesis core simple enough to be able to build it standalone without glib, then it would probably satisfy those cases where glib isn't available. Probably doesn't need to be multi-thread capable in that case either, so events are not queued, mutex operations become void, etc. 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
Wise words indeed! Here is what I got: No man really becomes a fool until he stops asking questions. - Charles Proteus Steinmetz (1865-1923), German-born American electrical engineer, inventor
I hope my questions are not irritating in their simplicity :-)
Regards, E |