Most of the binary (native code) modules, and in particular, the Eelium ones, should be possible to compile to DLL/so/dylib, and loaded on demand. For maximum portability and flexibility, it should remain an option to compile these modules for static linking as well, in a similar fashion to how they're handled now.
There was some work done on this long ago (before 0.3.x, IIRC), but it was abandoned due to various issues with how EEL used to handle imports, and also, design issues with SDL 1.2. Since then, the module handling has been refactored, and SDL 2.0 (see #71) integrates in a much cleaner fashion than 1.2.
One remaining problem is that shared libraries linking to symbols exported by the loading executable is not portable. (This happens when a binary EEL module tries to call EEL core functions when EEL is statically linked into the host application. It should be fine as long as the EEL core is also a DLL/so/dylib...)
The most portable solution is probably to provide the EEL core API via a struct of function pointers or similar, passed to the module init function. This also has the upside of allowing host applications to keep multiple isolated EEL "domains" in one process (for example, cleanly separated standard and hard real time domains), which can even use different EEL versions.
Most of the binary (native code) modules, and in particular, the Eelium ones, should be possible to compile to DLL/so/dylib, and loaded on demand. For maximum portability and flexibility, it should remain an option to compile these modules for static linking as well, in a similar fashion to how they're handled now.
There was some work done on this long ago (before 0.3.x, IIRC), but it was abandoned due to various issues with how EEL used to handle imports, and also, design issues with SDL 1.2. Since then, the module handling has been refactored, and SDL 2.0 (see #71) integrates in a much cleaner fashion than 1.2.
One remaining problem is that shared libraries linking to symbols exported by the loading executable is not portable. (This happens when a binary EEL module tries to call EEL core functions when EEL is statically linked into the host application. It should be fine as long as the EEL core is also a DLL/so/dylib...)
The most portable solution is probably to provide the EEL core API via a struct of function pointers or similar, passed to the module init function. This also has the upside of allowing host applications to keep multiple isolated EEL "domains" in one process (for example, cleanly separated standard and hard real time domains), which can even use different EEL versions.
(Related to #118, #53, #115, #70, #47, and #68.)