Re: [fluid-dev] More on GLIB dependency.

[Ceresa Jean-Jacques]

Hello carlo,

>I hope that you find my message interesting.

 

Sure your message and work are interesting because it enumerates and points fluidsynth OS dependency.

 

Regardless of the method used to abstract this dependency, the most important is that any developer doesn't not be

forced to change any line of fluidsynth source code each time a new fluidsynth version appears.

In the other case, i am afraid that anyone are still obliged to stay with Glib. After all, the only issue with Glib dynamic library is that there are uselessly fat.

 

The method presented is interesting but needs explanations about all the steps to do using this stuff through a simple example (i.e a mutex functionality).

All the best and again happy new year.

jjc.

 

 

 

 

 

> > Message du 31/12/17 15:22
> > De : "Carlo Bramini" <address@hidden>
> > A : address@hidden
> > Copie à : 
> > Objet : [fluid-dev] More on GLIB dependency.
> > 
> > Hello, Nowadays, the differences between the sources into main repository and the ones of my FluidSynth build without dependencies to GLIB are much less than the past. I decided to post this message for resuming my results. At the time of writing, FluidSynth has a good abstraction of the resources, so it is almost possible to switch between the two environment by replacing these files with others modified: CMakeList.txt src/config.cmake src/utils/fluid_sys.c src/utils/fluid_sys.h src/utils/fluidsynth_priv.c and adding these new ones: src/utils/fluid_sys_win32.c src/utils/fluid_sys_glib.c src/utils/fluid_sys_posix.c src/utils/fluid_sys_atomic.c with the functions that you could imagine. fluid_sys_atomic.c implements atomic access by using a mutex object and it could be used in case that the feature is not directly available. Win32 and GLIB have it, POSIX has not, so fluid_sys_posix.c is the only source to use it at the moment. fluid_sys.c provides timers, BSD network sockets, logs, profiling and high level input/output stream functions (gets, printf, etc). The other usual functions are provided by the newly added files. The key of implementation for the layer between the operating system and FluidSynth is the fluid_sys_object_t structure. typedef enum {     FLUID_TYPE_NULL = 0,     FLUID_TYPE_MUTEX,     FLUID_TYPE_THREAD,     FLUID_TYPE_SOCKET,     FLUID_TYPE_ISTREAM,     FLUID_TYPE_OSTREAM,     FLUID_TYPE_ICONSOLE,     FLUID_TYPE_OCONSOLE,     FLUID_TYPE_MAX } fluid_type; typedef struct fluid_sys_object_t {     fluid_type type;     void      *priv; } fluid_sys_object_t; The "type" member of the fluid_sys_object_t can assume one of the values of the 'fluid_type' enum, so it can address a mutex, a thread or other things with the purpose that you could imagine by reading the name assigned to that value. The "*priv" member will point to some private data and its meaning will vary depending on the target OS. For example, the mutex object is declared as an alias of fluid_sys_object_t: typedef fluid_sys_object_t fluid_mutex_t; Some helper functions are declared, for example: void _fluid_mutex_lock(fluid_mutex_t *); And, for minimizing the impact to the sources, the usual macros used in the sources are declared to something like: #define fluid_mutex_lock(_m)        _fluid_mutex_lock(&(_m)) I also did a second branch with functions instead of macros. In this way, pieces of code like this: fluid_mutex_lock(mutex); fluid_mutex_unlock(mutex); needs to be fixed to: fluid_mutex_lock(&mutex); fluid_mutex_unlock(&mutex); Not too much difficult afterall, only 7 files need this fix: Fluid_cmd.c fluid_midi_router.c fluid_seq.c fluid_defsfont.c fluid_event.c fluid_synth.c fluid_settings.c Since these functions are not exported as public API, it just depends on what people would like to see. Perhaps my new handling of streams and files through the fluid_sys_object_t may be found useful also in the current code. Few functions have been added for streams and it is interesting to notice how some pieces of code are simplified. Some of these functions are: fluid_istream_t fluid_istream_open(const char *fname); void fluid_istream_close(fluid_istream_t istream); int fluid_istream_read(fluid_istream_t in, void *ptr, unsigned int size); int fluid_ostream_write(fluid_ostream_t in, void *ptr, unsigned int size); For example, this is how the fluid_source looks now in my sources: int fluid_source(fluid_cmd_handler_t* handler, const char *filename) {   fluid_istream_t file;   fluid_shell_t shell;   int result;   file = fluid_istream_open(filename);   if (file == NULL)     return -1;   fluid_shell_init(&shell, NULL, handler, file, fluid_get_stdout());   result = (fluid_shell_run(&shell) == FLUID_THREAD_RETURN_VALUE) ? 0 : -1;   fluid_istream_close(file);   return result; } Using these functions and eventually expanding them seems also to open the door to other solutions, for example receiving shell commands or midi events also from a pipe, an MS Windows mailslot, an UNIX socket, a physical UART port, without changing the remaining code. I hope that you find my message interesting. Sincerely. _______________________________________________ fluid-dev mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/fluid-dev