I'm not really in favor of any of those things - simply because the de-facto standard is the 'autotools' route. It's certainly not as nice for the developer/maintainer of the package - but for the end user, having anything other than this is a real pain.Erwin Coumans wrote: With respect to multi-platform building, I can recommend adding CMake support, which I also do in Bullet. It automatically recognizes/finds Glut on Linux/Apple/Unix. Win32 glut lib is included with Bullet sources. CMake can autogenerate Makefiles, projectfiles (Xcode,KDevelop,MSVC) etc etc. You can still include manual makefiles obvious, having CMakeList.txt and Makefile is fine. In fact, in Bullet I ship with jamfiles too, to provide some choice ;-)
I have a pretty well-stuffed Linux box with 100% of SuSE-professional's applications installed on it. When I grabbed Bullet, I couldn't build it because I didn't have Jam. So I had to download it, install that and THEN get Bullet compiled & installed. Adding extra steps like that is *DEATH* to OpenSourced games and such. I'm a passionate minimiser-of-end-user-dependencies - so I'll fight with automake/autoconfig just because 100% of people have it already.
However, I don't plan to release what I have as a separate package. When (if!) we all like it, it should be subsumed into Bullet and should therefore build with whatever Bullet uses (even though I disagree with that!).
Incidentally: Redistributing modified versions of GLUT is contrary to it's license terms - so nobody can fix bugs in it, etc. You might want to use 'freeglut' instead which uses an Xfree-style license that's almost identical to the Zlib license. freeglut is one of my projects - so I'm biassed - but right now, it's more stable than real GLUT and it has vastly better licensing terms. It's 100% GLUT compatible - so it's an easy change.