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
how to build
-
- Posts: 4
- Joined: Fri Sep 22, 2006 11:13 am
-
- Posts: 4
- Joined: Fri Sep 22, 2006 11:13 am
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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
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
-
- Posts: 4
- Joined: Fri Sep 22, 2006 11:13 am
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
So I think I will wait a bit until Bullet stabilizes before trying to package it
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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
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
-
- Posts: 127
- Joined: Sun Aug 13, 2006 4:41 pm
- Location: Cedar Hill, Texas
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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.SteveBaker wrote:So how do people get bug fixes?
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
-
- Posts: 127
- Joined: Sun Aug 13, 2006 4:41 pm
- Location: Cedar Hill, Texas
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.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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
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