Box2D Forums

I appreciate efforts to make Box2D work well on Linux and other gcc platforms.

We had a poll a while back about separating header files:
http://www.box2d.org/forum/viewtopic.php?f=3&t=655&p=4058

Having Box2D.h off in some separate directory means that all the classes need to be defined in that file, like glui.h. IMO this would break the modularity of the code. We cannot require the user to define some other include directories in order to include Box2D.h.

Currently, the Box2D.h file is optional. You are free to include only the header files you need.

I want to ensure that Windows developers can double-click the sln file and press F5 to run the testbed without installing files in separate places or defining include directories.

I like the idea about putting glui and freeglut into the TestBed directory. They are not needed by the Box2D library.

We cannot have an sln file at the top level because we might need to support multiple versions of Visual C++.

We made a lot of directory changes at the beginning of Box2D development, taking into account Java and Flash developers.

Branches make sense to me if multiple people will be working on a separate branch, otherwise you can just merge. Any branches should integrate with the main branch asap. We don't have the resources to support multiple branches.

I suggest taking a look at other libraries like Box2D, such as Bullet and see how they are setup.

I would like to suggest an alternative: separate the headers but organize them together in the solution so windows users will get the same overview as before (e.g. everyting in ./Source) but Linux and Mingw users can easily copy the ./Include/box2d to their library.

Of course i will yield to the general opinion in this question if this feels to messy, but the work involved in "separating" the header files when installing on linux is much greater than just editing the vcproj-file to simulate the same effect.


Actually, this will allow you to have the same modularity as before, since Box2D.h will be in box2d/Box2D.h and Dynamics will be in box2d/Dynamics. The reason that this is necessary in Linux is because the Dynamics, Commons, etc... should not be directly in the library include directory since it clutters it up. And this will force code examples to be different under linux and in windows, since the header files will be repackaged under linux anyways. (it would be #include <Box2D.h> in windows and #include <box2d/Box2D.h> under linux).

To adjust the linux release to fit the current scheme is simply a greater task than just having another subdirectory. The extra subdirectory will also ensure that code examples stay platform independant (Without having to rewrite the headerfiles just for linux).


Same goes for an extra subdirectory, the only difference is that you use, for example: #include <box2d/Common/b2Math.h> which in my opinion is much nicer when you use a global library.

Same would go for windows if you just used the ./Include directory in "additional includes".


I've ensured that they can do just that, currently it's just to double-click the Box2D.VC9.sln (for visual studio 9), i am going to modify the old one to work the same for Visual Studio 8.

I personally believe that this is much clearer than having to go into the ./Build directory to find out how you can build the library, especially when working in a terminal (like when compiling with msys/mingw under windows for those who doesn't use visual studio).

Multiple versions of visual studio could be achieved by having a file named Box2D.VC8.sln in the root. I am working on it right now.


Thank you, i especially liked that part aswell .


I just want to take Linux, Freebsd and Solaris (whatever) into account aswell. This library is exquisitely cross platform since it uses only basic C features (in a c++ manner). I would love to se it's filestructure perfected aswell!


A branch would have been nice when i was developing this branch, since that would mean that people very easily could have checked it out and helped me, so patches would have been as easy as 'diff svn'. A tags directory would also be very nice to have, since it would allow you to forget which revision number was which release (just svn export the trunk into tags/Box2D-<version> and add it). And people downloading the library or a specific version wouldn't have to know either (or ask us for help about it).


I have, under Linux they use a painful keep-track-of-where-all-files-should-end-up-seperately approach. I firmly believe that the ./Include approach would save us a lot of pain and labour on the Linux side, and virtually cause none on the windows.


I neglected to mention the part about flash and Java, since i don't understand how that is relevant.

Okay, so it sounds like you would retain the directory structure for the Include folder. Would there be some installation procedure on Linux that copies the headers to /usr/include? If so couldn't it just copy the whole source tree (potentially nuking cpp files)? Box2D is not very big, so even having the cpp files in the include directory wouldn't be a big deal.

Are you unable to make a branch with your current privileges?

Please add a level or two to your proposed directory structure.

I looked at Bullet, it's Cmake files are perfectly capable of discerning between .h and .cpp, which are lumped together in Bullet exactly as Box2D. If not with some file matching, then at least with manual lists, like the current makefile does.
There is no *checked in* include folder at all (the equivalent files to Box2D.h reside in src/), but Cmake either generates an include file with just headers, or it installs the thing straight into /usr/include/. Either way, it seems like it is doing some acceptable Linux stuff despite an essentially identicaly structure to Box2D.

And this is the manner in which the headers are installed:



And yes, it uses a pattern matcher to find it's header files. But it also tracks them by hand to make sure that the binaries can find them.

If I were a package maintainer i would be pretty pissed at them, also note that i couldn't find any Linux friendly packages of bullet physics.


This is an excerpt from their HelloWorld example:



This means that they are expecting the header files to either be manually added (by specifying an additional include path) or for them to be directly under the include directory. Which any sane Linux package maintainer would call a bad convention.

I did however notice that bullet physics did not use relative include paths, which basically means that a nifty Linux guy could easily "fix" the headers by a few lines of scripting. Allowing something like this:



But that would mean breaking the HelloWorld example, or have different compilation instructions for Linux.

I strongly prefer the second example, and if the files arent organized under a box2d directory directly, it will be scripting nightmare to get it like that when installing on Linux.

This is also an issue on windows if you prefer to compile your programs using mingw.
In Visual Basic it is not an issue, since you always add additional include paths.

This is the user scenario I am trying to achieve under Linux:

Someone sees that box2d is a cool physics library and types the following in their prompt:


They then paste the helloworld example into a file they name main.cpp and types:


Also, I think am able to do branches, i just wanted your O.K. to reorganize.

P.S. I'm truly sorry for making such huge posts, I am just trying to describe the issue so windows users will understand properly.

edit: removed a P.S. that made me sound more an asshole than I really am.

Please make a branch and I will check it out this weekend.

I will also be working on the spam this weekend.

I think the hello world excerpt you've got there is not indicative of how it should work. In fact, I cannot find it myself. Bullet's naming conventions make it clear to me that the include root should be src/, as this contains 3 files prefixed with "bullet" which are there to quickly include the whole library, and then a few folders that are meant to be semi-separate libraries (they also start with "bullet", generally). The cmake agrees with this view. Nesting in a "bulletphysics" folder would be redundant. Box2D might need that wrapper because "Dynamics" and "Collision" are not acceptable names for the global space.

If you have a CMake that produces the correct include files, how is that difficult for a package maintainer? They can run CMake to get the same header files, for their packages.
Also, given there don't appear to be packages at the moment, I think the main goal should be that "cmake ; make ; make install" (or whatever the right sequence is) works, not making packages easy.

What i was trying to say was that bullet physics doesn't install in a nice way on linux, since it should have been wrapped in a subdirectory of /usr/include (in my case /usr/local/include since i didn't want to clutter my /usr/include).
And you are right, Collision/Dynamis/Common is not an acceptable naming scheme directly in the include directory, that was the point i was trying to make.

It's valentines day tomorrow, so i will try to branch tonight. I take that as an O.K. to create the trunk directory aswell.


Since they cannot easily be packed in a manner which would allow alot of code examples to compile without problems, all the header files would have to be modified in order to get it to work (probably after cmake has been run).

I looked things over. Thanks for your work on this udoprog!

Here are my proposed changes to the trunk:
1. Rename Source to Box2D.
2. Get rid of relative paths in include statements. All include statements should look like this:

3. Put all make/project/sln files into subfolders in the Build folder.

Justification:
1. This will give Linux users an include path that does not clutter /usr/include. The Linux installer will have to copy the Box2D folder to /usr/include, possibly skipping cpp files. This will keep header and source files together for ease of development. Having separate header and source directories seems to be a Linux convention rather than a functional requirement.
2. This should make include statements work on every platform.
3. This will keep the root directory clean and reduce naming conflicts. The Readme file should be enhanced to tell people about the various builds.

Please let me know if this sounds reasonable. I'm am hoping to make minimal changes to Box2D while satisfying the needs of all platforms.

Thanks, I've put together your proposed changes and will commit them to the branch sometime tomorrow (or monday).

After that i really need some mac/iphone/nds builders to take a look before I feel comfortable in committing to trunk, I am currently putting together an nds building and emulation environment, but this is not my regular cup of tea.

P.S. Renaming the Source directory (instead of having separate Include) was a very nice compromise!