On 6/30/06, Hans de Goede <j.w.r.degoede(a)hhs.nl&gt; 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?