packaging a lib which needs to be compiled in different ways for different users

[Hans de Goede]

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?