#3: split Gem-core and Gem-objects

Contents

1. Motivation
2. Proposal
3. Risks

Proposed by

IOhannes m zmölnig

Proposal type

User interface

State

being-discussed

Motivation

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

Proposal

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.

Risks

this would need more ressources.

inter-object dependencies (shared code, that shouldn't go into Gem-core) are badly managable