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 <elem...@elementsofsound.org> 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 <rym...@gmail.com> 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 < >> k.s.matheus...@gmail.com> wrote: >> >>> >>> >>> On Wed, Jan 13, 2016 at 9:28 PM, Ryan Gonzalez <rym...@gmail.com> 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 >>> fluid-dev@nongnu.org >>> 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 >> fluid-dev@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/fluid-dev >> >> > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > 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 fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
