Hi,
I use since long time cmake but for example you don't have the x86 and x64 in one visual studio project, but that's not very important.
For example unreal engine has his build system coupled with a custom code generator, but this is not the question.
Is it better to have a custom build system or use CMake is enough for all situations ?
Thanks
I am a big fan of CMake, and one of the things that I really like about it is that it is flexible enough to cover almost every situation.
I've seen enough custom build systems to develop a nervous tick whenever I see one.. it is a pain in the neck to maintain for every incremental version of whatever build chain out there..
I especially like that it is so painless to build out of the source tree, and that it generally works right for every possible platform and compiler/tool combination.
It also makes it really easy to have several versions of the compiled code living together in harmony (64bit/32bit/MinGW/VS).
I would not use a custom build system.
Every time I have tried something else I have always come home to GNU make.
Like most "is it better" questions, the answer depends on the details.
If CMake, or GNU make, or whatever other make program satisfies all the details you need for your project, then it is adequate.
There may be other build tools that provide a better solution to the specific steps your project may need. If your project happens to be better suited to building through Ant, or Gradle, or Maven, or Boost.Build, or Perforce Jam, or some other tool, then use whatever tools work better for you.
My two cents: I honestly can't imagine making a better bespoke build system than what already exists. In my experience, a build system is to be leveraged and extended, but not replaced -- that is, when you feel limited by it, its usually because you don't fully understand how to use or extend it with custom steps.
But its absolutely the norm that a complex project *does* extend its build system, it won't every last thing you need out of the box. And they're built to be extended with custom steps -- there are hooks all over to allow you to interject into the build process.
But fully custom, or even heavily modified (beyond easy recognition) or just plain complicated builds, are to be avoided. I had a gig once where my job was to perform static analysis of Xbox 360 titles and report back where there were dangerous practices or performance anti-patterns, so we'd get projects from various AAA studios. Once there was one with a very large and complicated build system. The normal process was that there was a Wisual Studio project and it was just good to go, but this one with the complicated build system was crazy -- in the end, what they ended up doing was having their build engineers create us a Hyper-V image on a physical hard drive and literally shipping it to us overnight. Even then, we had one of their build engineers on-call who would remote into the virtual machine to fix things when our tools changed how things worked (which was usually not an issue) -- they also were doing things that broke our tools, like issuing *single compiler commands* that spanned larger than 4096 characters in length (which exposed an incorrectly handled buffer copy in our tool, and took us a week to figure out).
Long story short, bespoke systems are usually brittle and often complicated, almost by definition. Existing build systems do a good job at the job they're meant to handle, otherwise they would not be so widely spread. Attempting a bespoke system on your own means you have to do all that mundane stuff just as well as the others before you might even get to gain any ground with your unique vision -- unless its a requirement, you're probably better of extending one of the existing systems with what you need.
I like CMake, its not perfect, but I wouldn't want to keep 3 or more build systems in sync for multi platform development, sure you have to change compiler flags from Linux to Windows and a lot more, but at least you do it in just one place. The fact that a lot of open source libraries use it also makes it easier to add them to your own project and build them yourself in case you like that kind of thing.
But if you're targeting Windows with VS and nothing more, I see no problem in just commiting your solution and project files onto your versioning system.
Custom build systems may take time to learn/understand to use for newcomers into your project, chances are, they may already know CMake.
CMake wants me to generate a new project for each platform, which might seem fine to someone coming from a makefile background, but is pants on head retarded in practice...
I have to generate x64 and x86 projects (editor is x64 and engine is x64 for the editor and x86 for the game), launch each time cmake-gui is not nice, the only solution I found is to make one .bat for windows and surely one .sh is needed for unix. Maybe add the compile in the .bat and .sh could be an option to batch both things in one time.
I think, Premake is much easier to program the script for than cmake (lua vs. weird custom cmake script) and it can (batch-)generate all projects/makefiles for all systems on a single system, whereas cmake would need to run on same system you need the project/makefile for.
The downside is its a less tested system and may miss some feature you need, as it got not as many people maintaining it (though my impression is, that new features get implemented first for VS-projects).
Using a well-written makefile extended with custom python tool scripts as needed has worked very well for us (currently three small scripts so far, whenever we need to add some kind of build pipeline that can't be done easily from within make or with standard tools we just write a small custom input/output tool for it, and it just works). Admittedly in our case we need quite close control over what the compiler is doing and command line scripts synergize very well with makefiles, hence our choice.
In most situations using CMake would probably be faster and simpler to get your project out there on as many platforms as needed, if your project does grow beyond CMake's capabilities, well, you'll spend a week or two switching over to something better more appropriate for your project's current state, no big deal. Plan ahead, but don't be afraid to refine decisions throughout your project's evolution.
