Box2D Forums

Update: Branch is now in svn, check it out with:


If you need instructions on building, see the Readme.txt in which i have added extensive amount of contents.

Please test it and report problems to me, I would also appreaciate if someone could look into the IPhone build, have in mind that ./Include is still under discussion and might be changed in a not-so-far-away future.

Currently confirmed working for:
Debian GNU/Linux (using cmake or gnumake)
Windows Vista (VS9/Mingw) (using cmake or VS9 solution)
VC8 build system is on route
Need Iphone and NDS builders to test and fix against this!

If you feel like you can test/fix the other platform builds, feel free to do so!

Since I wrote the makefiles let me tell you why I designed them the way they are.
1. To support development of box2d applications and box2d itself. This is why the makefiles automatically generate dependency files and why the code is built in place with relative paths. I have actually built about 10 different checked out versions of the code over time so my applications point to the appropriate root. The idea of installing a single version into a standard place doesn't work for me.
2. To allow multiple architectures to compile simultaneously. Currently these include fixed, floating point, and nintendo ds architectures and it is relatively simple to add your own.
3. No changes to the box2d source files themselves. The source code was developed using a windows based development environment which I do not use or understand. I took the source code as a given and wanted to build a makefile that would not, for example, rewrite all the headers.
4. Allow separate compilation of the library and the examples. A top level make will make everything, but if you cd to the Source directory and run make you compile just the library.

I have a couple of patch files in the Linux (ubuntu) thread that fix an issue with freeglut include files and to rewrite and install box2d headers and libraries into some "standard" places - things that other people had requested. Hopefully these will be applied to the code base eventually.

Some issues that I have not dealt with are how to handle contributed pieces of the library, detecting proper installation of glu and gl, and the whole "configure" approach to building the makefiles themselves.

Other people have developed makefiles for other forms of make, but I prefer gnu make

Guys, I just wanted to say that I support all these efforts, though I do not use Linux or the tools in question myself so am unable to contribute to the discussion. The wiki article makes it clear to me that at the moment it's impossibly confusing to set up on Linux, which must be the opposite of what you are used to.

I'm happy to commit changes to the library, once you come to a common consensus. I'd rather not see heavy changes to the structure of the library though, that'll be a pain for all the people happily using it already, and you are restricted from making changes which prevent it working at all on non-Linux platforms. This means as much as you might want it, you cannot rely on people using make/Cmake to build the library, it is one of several options. I am aware Cmake is cross platform, and therefore theoretically it is possible to drop everything else, but I don't think this is quite as flexible as just offering several project files, particularly as there are customizations for the Testbed occasionally made. E.g. recently an iPhone project has been made. Not using Cmake, I'd need to hear a more convincing argument for why it is the end-all of build systems.

On to my thoughts on individual issues:

No contrib directory: As stated, make/Cmake is not going to be the "only way" of making the library available. Not everyone has the luxury of automated downloads etc, nor is it desirable. I think the benefit of inclusion outweighs the space saving. Contrib also serves a purpose as for general "stuff" related to Box2D, but not an example or meriting library status.

Build directory: I don't like the idea of moving stuff to the root directory, it'll get pretty cluttered that way (particularly as VS at least autogenerates a dozen files or so next to the .sln file). Separate folders also makes it clear that this is a varying list. I'm almost inclined to suggest going in the opposite direction, and moving the makefile into the build directory instead. Certainly, by all accounts Source/makefile is a very confusing location. If you want to rename it, I'm open to suggestions.

I'm not sure why you want trunk & branch folders. So far, there has been no need to branch the project (though the work on changing the event system could do with it, honestly), but it's surely a developer decision. Unless you want to commit, I cannot see why you cannot create your own branches, or merely have several working directories.


TL;DR: Any Linux users, please work together to come to a solution, and then come back to me (or better, Erin, if you can get a response).

I noticed that box2d uses a modified version of glui, which of course cannot be discarded since it would break the build on any system.
So removing Contrib is definitely out of the question.
Instead, i created a new Contrib under Examples/TestBed which hold the library dependencies for the TestBed only. This should give clarity to what belongs where.



I've configured a VS9 project to but all output in /Output/<project>, the sollution is in the root, but the project files are in /Build/VS9.
This makes sure that there is minimal clutter in the root, and you still can catch what available builds there are at a glance.



Currently i really feel the need to have the branches directory, since i have to distribute my changes "as a whole" or one giant patch.
There is not nice way for me to integrate any changes that might be done to the library in the future either.

Have a look at the link in the first message and tell me what you think.

I believe that we are gonna have to write the build code for NDS seperately, or do some serious hacks for cmake. So it would probably be nice to have that as Makefiles, since it is only the box2d core library that needs to be compiled.

The current Makefile's are a good base for doing this.

Here is a patch file that contains some of the other patches and code added in the wiki. It contains:

1. The "make install" patch. You can run make install from either to top level directory or from Source. Currently installs into /usr/local/ but you can change that in Source/Makefile. Only the libraries and headers are installed, not the testbed.

2. The freeglut patch.

3. The shared library patch. Shared versions of the library are built but the testbed links to the static library so you do not have to install to built the testbed.

4. Reordered the build so that the library Source is built first. This way if the testbed fails to build because you haven't installed opengl and glu you still build the library itself.


Instructions to build:

1. Check out box2d. Apply the patch by running "patch -p0 < box2d_makefile_update.patch"
2. Make sure you have installed opengl and glu. These are not part of the box2d but are used by the testbed.
3. Run "make"
4. If you want to install the floating point version of the library and headers into /usr/local (or some other place) run "make install", otherwise you can reference them in the library at Source/Gen/float/
5. Run the testbed: "Examples/TestBed/Gen/float/testbed"

If someone could apply this patch to the svn base code that would be nice. It only touches the makefiles.

As BorisTheBrave mentioned, an alternative way to handle makefiles and the files that they generate is to put them all under a single directory. To that end, I've rewritten the makefiles to run from a single directory: Build/gnumake. I've attached those makefiles. Just untar them at the root. To run:

cd Build/gnumake
make

The results are in put into the Gen directory (actually Build/gnumake/Gen). For example, the testbed ends up in Gen/Examples/TestBed/float/testbed.

If this general approach is preferred then I could see other makefile systems (such as cmake) being implemented in a similar fashion, removing all of the makefiles and other make related files (like cmakelist) from the main source trees.

BTW, all of the previous features of the makefiles are still present including "make install" and the building of floating point, fixed point and nintendo ds versions of the library. In addition if you just want to make the box2d library you can run: "make -f Makefile.Source"

edit: done, your makefiles have been integrated into the branch, see the link at the top. The makefiles will now generate a /Gen directory with a structure that is inherited from where it was built.

edit2: Noticed a small issue when linking the testbed binary, it automatically chooses the .so (since that has precedence) which means that the library must be available in your LD_LIBRARY_PATH when running the testbed. The easiest sollution is to copy the corresponding version of libbox2d.so to /usr/lib when running, but a static compile should be made available using makefiles aswell.

I integrated the buildfiles into the svn branch, will upload it later today. Some small issues which was corrected.

But i don't like Makefiles for two reasons:
- It is difficult to check for existing resources (libraries/compilers etc...) and that tend to give you alot of output which you have to be good at enterprating to debug.
- Maintenence tend to quadruple as the project grows.

P.S. you can build the fixed float version by setting the variable TARGET_FLOAT32_IS_FIXED inside build/CMakeCache.txt when it has been generated. As for NDS, i'm working on it.

edit2: Noticed a small issue when linking the testbed binary, it automatically chooses the .so (since that has precedence) which means that the library must be available in your LD_LIBRARY_PATH when running the testbed. The easiest sollution is to copy the corresponding version of libbox2d.so to /usr/lib when running, but a static compile should be made available using makefiles aswell.

To fix this you can link the library with a complete path instead of using the -lbox2d. Look at the makefile in the tar file to see what I did:

Gen/$(PACKAGE)/fixed/testbed: $(FIXED_OBJECTS) Gen/Source/fixed/libbox2d.a
g++ -rdynamic -o $@ $^ $(LDFLAGS) Gen/Source/fixed/libbox2d.a -lglui -l\
glut -lGLU -lGL

Yes thats good, by default the testbed should be statically compiled .

I think I accidentally edited that out when putting your makefiles in the branch.