#3: split Gem-core and Gem-objects
- Proposed by
- IOhannes m zmölnig
- Proposal type
- User interface
Gem comes with a number of dl-dependencies (esp. on linux), which makes it hard to distribute a binary that works on a certain machine/distro/...
the idea is to distribute these dependencies onto several binaries, so the core-functionality can be used even if some special libraries are missing on a system
it would be nice to break the entire Gem-library into single externals
(which would only load after the infrastructure library has been loaded)
one huge pro of this would be, that dynamic dependencies of single objects
(e.g. codec-libraries for movie/video decoding) would not affect Gem in its entirety.
probably this is also a solution to having MMX/SSE2/AltiVec versions of an
object in parallel.
this would need more ressources.
inter-object dependencies (shared code, that shouldn't go into Gem-core) are badly managable