> I was thinking to adjust things in a manner that it could run ALSO without GLIB.
Sry, but I dont see that we can have one fluidsynth shipping for arbitrary users that doesnt require or use GLIB at all, and having another version of fluidsynth that uses GLIB. Imagine: Windows users will come upstream reporting bugs and I cant reproduce them. Why? Because there is some mistake/bug/discrepancy in how GLIB handles things compared to your custom OSAL that I as a Linux user am not using. > I made it working on Windows without GLIB [...] in my opinion I did it more efficient than the past and with some common parts. Cant tell anything concrete, still havent seen any code. But: Only considering the windows implementation for that: I can imagine what an insanely huge task it would be duplicating all of GLIBs functionality used by fluidsynth just in order to (optionally) get rid of it. Here is a (probably incomplete) list: * Threads * TreadLocalStorages * Mutexes * Condition Variables * Atomics * g_setenv() * Fixed width integers * Date and Time Functions (e.g. g_get_current_time()) * Shell commandline handling functions (e.g. g_shell_parse_argv()) And why only implementing them for Windows? Let's also do it for MacOSX, Linux and OS/2. How about BSD or Solaris so those can also get rid of GLIB? ... this would be a completely ummaintainable never ending story. It is not fluidsynths task to provide a portable OSAL library. That's what standards are made for (nowadays). > With pthreads or Windows API, We are 100% sure that we won't have functions that they will disappear from one version to another because they are deprecated and this is also visibible in your current code. Win32 and pthreads are not enough. And I would always prefer a few removed functions to that huge unmaintainable monster described above. So again, the only reasonable answer saying goodbye to GLIB can be moving to a new standard (C11, optionally with a mix of e.g. C++11). And the only reason NOT to do this NOW is because of lacking toolchain implementations. > For example, fluid_get_userconf() returns always NULL on Windows, while in my opinion it won't be a bad idea to query CSIDL_APPDATA with ShellAPI for retrieving this kind of information. Pull requests welcome. Tom 2017-10-14 11:35 GMT+02:00 Carlo Bramini <carlo.bra...@libero.it>: > Hello, > please excuse me if this message looks long... > > It was not my intention to make changes to Fluidsynth so that you won't be > able to run it with GLIB anymore. > I was thinking to adjust things in a manner that it could run ALSO without > GLIB. > Hopefully, it seems to me that Fluidsynth has been written (probably) by > thinking also on this subject, so I do not think that this task is > extremely complicated or hard to maintain. I did it, so I think I know what > I'm writing. Once things are implemented, I don't think they will need a > big maintenance. > Perhaps, it will be even easier to maintain. With pthreads or Windows API, > We are 100% sure that we won't have functions that they will disappear from > one version to another because they are deprecated and this is also > visibible in your current code. > > Beside the creation of a fluidsynth without external dependencies, I think > that there are some other things that could be useful. > > As I have written in my previous email, I used MSVC 6.0 for doing this > development. > The C version implemented in this environment is C90 and it has been a > good bench for testing the portability. > > Just to make an example, C90 does not implement variable length arrays. > However, it could be done with alloca() or _alloca() intrinsic functions, > if supported. > Fluidsynth already checks the presence of this feature, but it did not > allow to select something different than GLIB. > So, I implemented this thing in my new common part in this way: > > #if defined HAVE_VLA_SUPPORT > # define FLUID_DECLARE_VLA(_type, _name, _len) _type _name[_len] > #elif defined HAVE_ALLOCA > # define FLUID_DECLARE_VLA(_type, _name, _len) _type * _name = (_type > *)alloca(sizeof(_type)*(_len)) > #elif defined HAVE__ALLOCA > # define FLUID_DECLARE_VLA(_type, _name, _len) _type * _name = (_type > *)_alloca(sizeof(_type)*(_len)) > #elif defined HAVE_GLIB > # define FLUID_DECLARE_VLA(_type, _name, _len) _type * _name = (_type > *)g_newa(_type, _len) > #else > # error Support for variable-length arrays is missing on this system. > #endif > > Next to all these changes, I made it working on Windows without GLIB. > Perhaps you may find something similar to a previous version of > Fluidsynth, at least at first sight. > Afterall, there are not many other ways to do it, like starting a thread > for example. > However, in my opinion I did it more efficient than the past and with some > common parts. > > I also noticed that some thing are also not implemented in the current > code base. > For example, fluid_get_userconf() returns always NULL on Windows, while in > my opinion it won't be a bad idea to query CSIDL_APPDATA with ShellAPI for > retrieving this kind of information. > > Under this view, it does not look bad or hard to maintain a specific layer > of 10KB for a particular platform. > > If you prefer, I could start to share just the changes that do not impact > with current GLIB layer and, if you will find them useful, you could > integrate them, or you could trash them as you wish if they won't look good > for you. > > In the meanwhile, when working on my homebrew digital piano, I have also > compiled and apparently made working Fluidsynth on my evaluation board with > an LPC1788 from NXP with emIDE as development environment and newlib as C > library. Here there is still lot of work to do because I must a new code to > forward the MIDI events from the matrix of the piano keyboard connected to > this microcontroller and write another piece of code for emitting some > audio output. I could use NuttX OS (with full pthread and posix support), > GNU Pth (cooperative pthread support) or a very simple cooperative > multitasking made by me with setjmp/longjmp inside fluid_* functions, > probably this last solution simplifies a lot the coding since it will work > on all implementations of libc as last resort. During this coding, I > noticed that some thing could be improved regarding the RAM usage: if you > have some experience in the world of embedded systems, you will know that > the volatile RAM is a limited resource and all constant data should be > moved into the flash memory. I have also an external SDRAM, but I did not > used it intentionally, to see where the weak area are. So, some fixes have > been made in my build also for this. Probably, it won't work well because a > Cortex-M3 has not an hardware FPU, so I will need to migrate to an M4 or an > M7... But this is another story. > > Sincerely. > > _______________________________________________ > 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
