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

[Hans de Goede]

Christopher Stone wrote:
> 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?
> 

Erm, no I think the effort needed to make that work is not worth the gain.

Regards,

Hans