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 <rym...@gmail.com> 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 < > 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 > >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
