Christopher Stone wrote: > On 6/30/06, Hans de Goede <j.w.r.degoede@xxxxxx> wrote: >> Hi all, >> >> I and Eitch are currently looking into packaging ode (a physics >> library). Ode uses OPCODE which is a 3D collision detection library. >> >> Opcode is included in ode's sources but is used by many opensource >> projects to name 2: >> -crystal space >> -ode >> >> Opcode can be compiled to use either callbacks to get the next object >> from a list of objects that need to be checked for collisions _OR_ to >> use an array of pointers to these objects. however it cannot be compiled >> to support both! And it has more compile time options like these which >> are likely to be used in a mix and match style by other projects. >> >> Also all projects using opcode seem to have made their own additions to >> it, now these extra overloaded operators and methods could be merged >> into the mainline, but thats going to be a pain, because then each time >> a new package using opcode is going to get packaged any functionality >> added to opcode by this application much first be merged into our >> seperate opcode package. >> >> And even with that done we still have the compile time options. Notice >> that I gave one example, but that there are atleast 2 options which lead >> to incompatible libs, so thats 4 versions of the lib. and that is only >> after checking the 3 options modifed from the default settings by ode >> and crystalspace, so thats 2 out of 3 :| >> >> All in all this leads me to the conclusion that its best to make an >> exception to the rule: "libraries with a seperate upstream yet included >> in the sourcetarbal must not be used" in the case of opcode. >> >> Does not following this rule sound reasonable / any objections? > > Would it make sense to have ode-opcode, demo-effects-opcode, > crystal-space-opcode etc packages? That is, split the opcode part > into a seperate subpackage that does not require the main package, and > if one project can use another's opcode it can do so? > Erm, no I think the effort needed to make that work is not worth the gain. Regards, Hans _______________________________________________ @xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-games-list
