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

[Christopher Stone]

On 6/30/06, Hans de Goede <j.w.r.degoede at 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?