[Top][All Lists]

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

Re: [fluid-dev] FluidSynth and glib

From: Element Green
Subject: Re: [fluid-dev] FluidSynth and glib
Date: Wed, 13 Jan 2016 16:06:30 -0700

I think the ticket system on SourceForge would be the best way to submit this:

Indeed, there isn't a lot of stuff that needs to be implemented to remove glib as a dependency, for a single platform/architecture.  Doing this in a clean and portable fashion however, leads one back to glib.  So the way I could see this working would be to have native support for certain key architectures which gets optionally selected at compile time which causes a platform specific header and C file to be built (the stuff in fluid_sys.[ch]) which supplies the needed macros and functions.  In order to do things properly, threading APIs like pthreads or Windows related thread functions would need to be used (depending on the platform).  Some of the atomic operations may require assembler (a lot of this can probably get lifted from glib), which ends up being compiler specific.  It may simplify things to only have libfluidsynth get built in these cases and leave out the fluidsynth executable.  That may cut down on some of the platform support that needs to be implemented.

I'm not really available at this time to assist with any of this, so hopefully some other developer will step up and help integrate such patches.

Best regards,


On Wed, Jan 13, 2016 at 2:06 PM, Ryan Gonzalez <address@hidden> wrote:
Well, the majority of g_* are wrapped with macros anyway, so it wouldn't be a major issue.

Would the developers of Fluidsynth be OK if I sent a series of patches to this list that slowly eliminated the need for glib? Unless you have another way of handling contributions or something....

On Wed, Jan 13, 2016 at 2:33 PM, Kjetil Matheussen <address@hidden> wrote:

On Wed, Jan 13, 2016 at 9:28 PM, Ryan Gonzalez <address@hidden> wrote:

Similar things for the rest of them. This doesn't seem TOO bad...

Maybe it would be a good idea to just implement the necessary
"g_"* functions for the needed platforms instead of creating a new API
doing all of these things?

fluid-dev mailing list

[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.

fluid-dev mailing list

reply via email to

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