how to build

pablob · Post by **pablob** » Fri Sep 22, 2006 11:19 am

Hi guys,

I am trying the library and producing a .deb package at the same time.
With jam the library builds fine, but at installation time, jam doesnt seem to support the DESTDIR make variable or anything like it, so it doesnt allow to install in a place other than /usr

cmake should support DESTDIR (as it produces makefiles), but when I do
cmake .
make

it gives this error:

Linking CXX executable CcdPhysicsDemo
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o: In function `CcdPhysicsDemo::initPhysics()':
CcdPhysicsDemo.cpp:(.text+0x959): undefined reference to `DemoApplication::LocalCreatePhysicsObject(bool, float, SimdTransform const&, CollisionShape*)'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o: In function `main':
CcdPhysicsDemo.cpp:(.text+0xd68): undefined reference to `DemoApplication::setCameraDistance(float)'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o: In function `CcdPhysicsDemo::~CcdPhysicsDemo()':
CcdPhysicsDemo.cpp:(.text._ZN14CcdPhysicsDemoD0Ev[CcdPhysicsDemo::~CcdPhysicsDemo()]+0x17): undefined reference to `DemoApplication::~DemoApplication()'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o: In function `CcdPhysicsDemo::~CcdPhysicsDemo()':
CcdPhysicsDemo.cpp:(.text._ZN14CcdPhysicsDemoD1Ev[CcdPhysicsDemo::~CcdPhysicsDemo()]+0x17): undefined reference to `DemoApplication::~DemoApplication()'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o: In function `CcdPhysicsDemo::CcdPhysicsDemo()':
CcdPhysicsDemo.cpp:(.text._ZN14CcdPhysicsDemoC1Ev[CcdPhysicsDemo::CcdPhysicsDemo()]+0xd): undefined reference to `DemoApplication::DemoApplication()'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o:(.rodata._ZTV14CcdPhysicsDemo[vtable for CcdPhysicsDemo]+0x10): undefined reference to `DemoApplication::updateCamera()'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o:(.rodata._ZTV14CcdPhysicsDemo[vtable for CcdPhysicsDemo]+0x1c): undefined reference to `DemoApplication::keyboardCallback(unsigned char, int, int)'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o:(.rodata._ZTV14CcdPhysicsDemo[vtable for CcdPhysicsDemo]+0x20): undefined reference to `DemoApplication::specialKeyboard(int, int, int)'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o:(.rodata._ZTV14CcdPhysicsDemo[vtable for CcdPhysicsDemo]+0x24): undefined reference to `DemoApplication::reshape(int, int)'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o:(.rodata._ZTV14CcdPhysicsDemo[vtable for CcdPhysicsDemo]+0x28): undefined reference to `DemoApplication::mouseFunc(int, int, int, int)'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o:(.rodata._ZTV14CcdPhysicsDemo[vtable for CcdPhysicsDemo]+0x2c): undefined reference to `DemoApplication::mouseMotionFunc(int, int)'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o:(.rodata._ZTV14CcdPhysicsDemo[vtable for CcdPhysicsDemo]+0x34): undefined reference to `DemoApplication::renderme()'
CMakeFiles/CcdPhysicsDemo.dir/CcdPhysicsDemo.o:(.rodata._ZTI14CcdPhysicsDemo[typeinfo for CcdPhysicsDemo]+0x8): undefined reference to `typeinfo for DemoApplication'
/home/pablob/bullet/bullet-2.0e/Demos/OpenGL/libLibOpenGLSupport.a(GlutStuff.o): In function `glutMoveAndDisplayCallback()':
GlutStuff.cpp:(.text+0x139): undefined reference to `DemoApplication::moveAndDisplay()'
/home/pablob/bullet/bullet-2.0e/Demos/OpenGL/libLibOpenGLSupport.a(GlutStuff.o): In function `glutmain(int, char**, int, int, char const*, DemoApplication*)':
GlutStuff.cpp:(.text+0x1a6): undefined reference to `DemoApplication::myinit()'
collect2: ld returned 1 exit status
make[2]: *** [Demos/CcdPhysicsDemo/CcdPhysicsDemo] Error 1
make[1]: *** [Demos/CcdPhysicsDemo/CMakeFiles/CcdPhysicsDemo.dir/all] Error 2
make: *** [all] Error 2

I dont know anything about cmake, so.. is this fixed on CVS?

Cheers
Pablo

pablob · Post by **pablob** » Fri Sep 22, 2006 12:04 pm

hehe, if I wasnt so lazy... this fixes it

in bullet-2.0e/Demos/OpenGL:

--- CMakeLists.txt~ 2006-09-11 07:10:40.000000000 +0100
+++ CMakeLists.txt 2006-09-22 13:01:03.000000000 +0100
@@ -59,4 +59,5 @@
GLDebugDrawer.cpp
GlutStuff.cpp
RenderTexture.cpp
+ DemoApplication.cpp
)

pablob · Post by **pablob** » Fri Sep 22, 2006 12:31 pm

mm the install target doesnt work...

How would you install it in the system? The libs don't have a "clear" interface (eg, which .h files should be in /usr/include? ) etc...

Erwin Coumans · Post by **Erwin Coumans** » Fri Sep 22, 2006 4:40 pm

Thanks, a recent file was not added to CMakeLists.txt.
The Cmake build should probably use a wildcard *.cpp to avoid this.
The library is not supposed to be 'installed' as a system library, but if you have some recommendations about a .deb package (what is that about?) please let me know. You use unpack it to where your other sources are, and use it from there. Bullet is also part of the Blender source tree, but that is a slightly older version. I don't have the resources to keep Blender up-to-date with the latest Bullet changes all the time, so system-wide headers is not really recommended.

A C API (in its own headerfile) might be added at some stage, but for now its more useful to use use the C++ classes as it is. The Bullet Collision Detection and Dynamics library has been designed with extensibility in mind.

Thanks,
Erwin

pablob · Post by **pablob** » Mon Sep 25, 2006 11:50 pm

A .deb file is the package format used in Debian and Ubuntu, as opposed to the RPM format that RedHat, SUSE and others use. They are not difficult to make, provided that the project build system provides a working 'install' target.

So I think I will wait a bit until Bullet stabilizes before trying to package it

Erwin Coumans · Post by **Erwin Coumans** » Mon Sep 25, 2006 11:57 pm

But that creates a system-wide library like bulletcollision.a and bulletdynamics.a in say /usr/lib and some headers in /usr/include ?

For physics, you usually don't want that. You use unzip the sources, or precompiled library, and use it 'in place'. I wouldn't recommend sharing the physics engine across the system. Each version has its own behaviour, and unless you don't care about the precise behaviour you need to stick with that version for a particular application.

With graphics libraries or sound libraries, you can mindlessly upgrade to the next version, and ignore the changes and few small glitches in performance, with physics you usually don't.

Thanks,
Erwin

SteveBaker · Post by **SteveBaker** » Tue Sep 26, 2006 4:44 am

So how do people get bug fixes?

Erwin Coumans · Post by **Erwin Coumans** » Tue Sep 26, 2006 5:20 am

SteveBaker wrote:So how do people get bug fixes?

During developing of a game, bugfixing a physics engine can be tricky due to behaviour change. Once the game is going 'gold', usually you don't want bugfixes in the physics engine. Perhaps bugfixes in the collision detection engine (due to missing/failing collisions perhaps). The game is tuned for certain behaviour, and due to many dependencies a change can have a global effect that propagates.

Basically, if you go for a system-wide physics library, bugfixes for one game can introduce bugs for the other. So just keep seperate copies, and if you want to fix bugs, just fix them in the local tree of the game.

Erwin

SteveBaker · Post by **SteveBaker** » Tue Sep 26, 2006 1:34 pm

I think it's still worth having a standard install path - and a 'make install' and 'make dist' (or should that be 'jam install' and 'jam dist'). People who have the problems you mention can still use the package in the way you describe (it's OpenSourced after all!) - but the rest of us, we can benefit from a standard path.

Erwin Coumans · Post by **Erwin Coumans** » Tue Sep 26, 2006 4:48 pm

For Windows, there is just projectfiles which don't 'install', and for OS X you can autogenerate Xcode projectfiles, which dont install either.

But for Unix and Linux in particular, both CMake and jam can potentially 'install' to a system folder. Let's first finish the cleanup, and get some cool GPU physics running

Erwin