Re: [fluid-dev] Role of glib

[josh]

Quoting David Henningsson <address@hidden>:
> 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? ;-)


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? ;)


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


> > 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?


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.


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 like yours better :)

Cheers!

Josh