CMake versus jam in bullet 2.73

[venzon]

Using jam, the output libraries I'm interested in are called libbulletcollision.a and libbulletmath.a. Using cmake, the output libraries are called libBulletCollision.a and libLinearMath.a. Why are these different? This makes it difficult for me to use bullet in my project, because I need to add complexity in my build files to detect which bullet libraries exist and link against the correct names. Am I missing some obvious way to avoid this?

[sparkprime]

They ought to both use the same case. I vote for lower case as that is more standard on unix. You should probably modify the script and put a patch in the issues tracker.

[Erwin Coumans]

Bullet is not supposed to be a system-wide installed library, but included inside a project instead. Apart from that, when you use Visual Studio, the library name will use the .lib extension instead of .a, so there is no standard way for the library names.

So I recommend to simply include Bullet inside your own project, and choose which build system you use yourself (make, jam, CMake etc).
Thanks,
Erwin

[venzon]

I recommend to simply include Bullet inside your own project, and choose which build system you use yourself (make, jam, CMake etc).

The way I currently distribute bullet is as a tar.gz file inside my project's release, and then the user is expected to untar bullet, run jam or cmake or make inside bullet (but not do an install), and then when they build my project (with scons) I link in the static libraries from the bullet tree (which will be in different places and have different names depending on which bullet build method they used). The way this is currently set up I have to support all of the bullet build options because I've found my users will randomly pick a bullet build method (and in some cases, only certain build methods will work on their platforms). Are you suggesting I go a step further and in fact make it so my build files actually build bullet as well (as if bullet was just a source module in my own project)? Is this how bullet is intended to be used?

Bullet is not supposed to be a system-wide installed library, but included inside a project instead.

Somewhat related, I've noticed that because the bullet build files include an install target, many users do install bullet system-wide, and this causes problems with the way I'm currently doing things. Because static libraries aren't really intended to be installed, but users do anyway, I end up with all kinds of nasty bugs when they link against some old, gimpy bullet static library they've got languishing in their library path. I suppose making my build files build bullet directly would address this problem as well.

[Erwin Coumans]

Are you suggesting I go a step further and in fact make it so my build files actually build bullet as well (as if bullet was just a source module in my own project)? Is this how bullet is intended to be used?

Exactly. It should be trivial to add the Bullet src folder to your SCons build system.

I end up with all kinds of nasty bugs when they link against some old, gimpy bullet static library they've got languishing in their library path.

You can always check the version of the library used, using btGetVersion(), from Bullet/LinearMath/btScalar.h:

Code: Select all

#define BT_BULLET_VERSION 273

inline int	btGetVersion()
{
	return BT_BULLET_VERSION;
}

But when you simply add SCons support for Bullet, you are safe.
Hope this helps,
Erwin

[venzon]

I wanted to come back and report that all is working well now that my own project's build process builds bullet. Thanks!