packaging a lib which needs to be compiled in different ways for different users
by 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?
17 years, 10 months
- 3
- 3
Testers with radeon 9600 or 9800 wanted for new 3D package
by Hans de Goede
Hi all,
I've just finished up packaging a 3D chess game called chess, which I
mainly packaged to have something to test OGRE an OO 3D engine.
I've finally managed to get everything to work, but unfortunately chess
is very slow on my radeon 9200, like 2 fps.
So I've got two questions:
-can someone with good 3D card be it with binary drivers test this for
me and see if it does work properly there?
-can someone with a radeon 9600 or 9800 who is using the new opensource
dri drivers for this card test this, to see how it works there?
You need to download (and build) the ogre, chess and coldet SRPMS from here:
http://people.atrpms.net/~hdegoede
chess needs both colder and ogre, so you must build and install those first.
For those interested here are the review requests:
coldet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196710
ogre: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196740
chess: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196744
Thanks & Regards,
Hans
17 years, 10 months
- 2
- 5
- ← Newer
- 1
- Older →