Re: [fluid-dev] FluidSynth and glib

[Element Green]

Indeed.  Probably the easiest would be to just lift the related bits from glib itself.

Best regards,

Element

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

May I try? :D

Pretty much everything outside of threading is really trivial. The wiki says the supported platforms are Windows, OSX, and Linux, and that it runs under Solaris and OS/2 but they aren't officially supported.

For atomics, glib seems to use GCC's C++11-style atomics. when it can, then it falls back to either GCC/Clang's built-in __sync atomic operations or Windows's atomic API.

For normal threads, glib uses pthreads on Posix and Windows threads on...Windows.

Maybe I'm just super nerdy, but this seems totally doable. ;)

On Wed, Jan 13, 2016 at 5:06 PM, Element Green <address@hidden> wrote:

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

https://sourceforge.net/p/fluidsynth/tickets/

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,

Element

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
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

--

Ryan

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

http://kirbyfan64.github.io/

 

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

--

Ryan

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

http://kirbyfan64.github.io/

 

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev