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?
Thanks and Regards,
Hans
p.s.
I know we have this rule, atleast I think we have this rule and we should have this rule, but is it written down somewhere?
On 6/30/06, Hans de Goede j.w.r.degoede@hhs.nl 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?
Christopher Stone wrote:
On 6/30/06, Hans de Goede j.w.r.degoede@hhs.nl 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
On Wednesday 05 July 2006 17:00, Hans de Goede wrote:
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.
+1
Regards, Hans
-
Christopher Stone -
Hans de Goede -
Hugo Cisneiros