However, more and more projects have begun using CMake so it can't be that bad.

I modelled my CMake system on Ogre's, once upon a time... That new dependency you need? Congratulations, you now own and maintain a Find<Dependency>.cmake file on N different operating systems, each with their own oddities. That compiler flag you need to set? It's different for every compiler, and you now need target-specific code throughout your build system. Need to sell your game on the Mac App Store? Guess what, CMake's support for packaging Mac application bundles haven't been maintained in years.

I'll grant you that CMake probably works really well for 90% of use cases. Sadly, if you ever need to step outside those dotted lines, it's really not worth the hassle.

These days I often just check in to source control an XCode project for Mac, and a Visual Studio project for Windows.

And really, really, really hope that someone writes an equivalent of Cargo, for C++.

I modelled my CMake system on Ogre's, once upon a time...

That was my starting point as well, but it is not well written. Not exactly an example of clean and modular CMake scripts.

I didn't know about XCode and CMake having fallen into neglect, but almost anything that has to do with Apple is arcane by design it seems.

I don't find the find_package system (pun intended?) to be too much of a hassle - seems to work great on at least Windows and Linux flavors. I tend to rely on environment variables a lot, though. Definitely makes it simpler on Windows which doesn't have a canonical file system. (/usr/lib, /usr/local, etc)

I am totally aware that CMake is not even close to being the magic bullet, but more often than not it is quite simply faster for me to just write a CMake script for a project than messing around and trying to fix broken VS projects.

And, yes: I do create a lot of CMake projects because not everything has been CMake'd.

And I have a tendency (hobby?) to constantly try out things, hence the need to create new projects on a regular basis.

So, in an attempt to connect our derailed post to the topic: I find that it is easier and less error-prone to create/maintain/handle projects outside of an IDE than from within.

That is my personal experience and thus not universally applicable (even though I'd love that to be the case )

I have a different story to tell

Congratulations on being part of the 90% use-case :)

(the other 10% of us have been waiting for robust support for building frameworks since 2007, and there is still no real support for plugin bundles)

I continue to think it's really a sad state of affairs when compared to the "just works" worlds of Java's gradle, Ruby's Gem, Node.js' Npm, or Rust's Cargo...

Npm, Gem and (I guess) Gradle are package managers, not cross-platform tools to manage build systems.

CMake is not, and does not try to be, a package manager with dependency management.

Biicode, however, is indeed comparable to Gem/Npm/Gradle but I find it to be too intrusive. It is built on top of CMake, which illustrates that you can build almost whatever you want on top of it. Perhaps that would make CMake more palatable to the 10% people? :)

I do not think it is fair to criticize CMake for not being what it is not intended to be. I like that it is not an operating system. :p

Just wondering aloud here, but could you make a case for a cross platform C++ build language that's part of the standard?

The language would just define dependencies, some basic compiler/linker settings (include/lib directories, etc). Each tool chain could interpret the settings as required, and any platform specific settings would go in a separate file.

I was thinking something like

/ SomeProjectDir
project.build                // project settings, dependencies, etc
project.visualstudio.build   // visual studio settings
project.gcc.build            // gcc settings
 + include
 + source
   file1.cpp
   file2.cpp
   file2.build  // file2 specific settings
   file3.cpp
   file3.gcc.build // file2 specifc settings on gcc

I know it'll never happen for political reasons, but would it be a) possible or b) desireable?

Npm, Gem and (I guess) Gradle are package managers, not cross-platform tools to manage build systems.

Npm is not the default build system for Node.js, but it does in fact support this use-case, and many developers and CI tools use it as a build tool.

Gradle and Cargo are full build systems, in addition to their package-management capabilties.

CMake is not, and does not try to be, a package manager with dependency management.

I never claimed it was trying to be - I'm saying it is an inferior product because it doesn't.

I wouldn't have to write my own FindODE.cmake for N different platforms if the build tool had a system for knowing where SDL would be installed...

Beats me why you feel you have to write your own Find_ODE.cmake module for N different platforms..

The Find_SDL module ships with CMake and works across all supported platforms (OS X included).

And I think it would be a trivial thing to get hold of a battle-tested Find_ODE CMake script as a result of a quick Google.

If it was me, in my projects, I would probably have queried for ODE and it's dependencies and if any of them aren't found, I would let CMake download/checkout, unpack and build and install (locally, into the build directory) by means of CMake's ExternalProject.

This discussion is getting us nowhere - it's a bit like complaining about how the alarm clock sucks because it doesn't brew coffee.

<edit>

I could ask why on Earth you would want to be using ODE when you could be using a hard-ware accelerated physics library like Bullet? But that would definitely derail the topic even further.

</edit>

The Find_SDL module ships with CMake and works across all supported platforms (OS X included).

Except it doesn't really work on the Mac.

Their FindSDL module is exceptionally good at finding legacy X11 builds of SDL (why, I have no idea - very few developers should be producing apps with non-native UI), and it generally also finds framework builds installed directly by the user. It doesn't ever find builds installed via homebrew (by far the most popular package manager on Mac), though for some reason it supports the venerable MacPorts quite well.

This discussion is getting us nowhere - it's a bit like complaining about how the alarm clock sucks because it doesn't brew coffee.

Is the purpose of a build tool not to build things? Is the complicated part of building things not dependency management?

If dependencies weren't the hard part, then any idiot could run gcc -o myapp *.cpp and end up with working software.

&nbsp;

Graelig, you did say that an IDE was a necessity. Necessity = something that is necessary.
That you didn't mean it, or decide to back out, that is not my concern.
And, you say that "it's just my opinion", which is correct.
What you write in your posts is probably your opinion, am I right?

I said it's almost a necessity, which I think is true. You can technically call VC++ without the IDE but why bother? You can't really set up make on windows, you have to use something like cygwin, and that is a giant pain.

As for my opinion, sure. But it is one that is easy to support.

Setting up a build environment without an IDE is not only easy but also much faster in my experience, if you are using a tool like CMake, SCons, and the like.
&nbsp;
I didn't say anything about writing a build chain in batch files, for Christ sakes!!
I said batch build. Kicking off a build without cracking open the IDE.
I have a growing suspicion that you are splitting hairs with me?
&nbsp;
Disclaimer:
This post contains opinions and observations and is not intended to be universally applicable. It just tries to broaden the picture by adding to the topic at hand.
&nbsp;
&lt;edit&gt;
Also, when I say that I am an Emacs user you seem to automatically assume that I am using it for C++ development, and that is extremely far from the truth. Have you read the previous posts in this topic, you would have learned that I am using Sublime Text now because I, like you, grew tired of being stuck in a configuration mire. Emacs is awesome, but Sublime Text gets the job done faster ((maybe not as fun, but definitely faster)).
For programming I use CMake and a combination of VS/QtCreator/Command-line.
I am not in a corporate environment, of course. So I am at liberty here. ;)
&lt;/edit&gt;

The topic of the thread is IDE vs Editor. So that is what I am discussing. Using things like makefiles is a part of using an editor, if you are using it for programming. If you are not talking about programming then you have gotten off topic.

You can't really do that in windows except in some goofy way like cygwin that's hard to maintain, and will wind up with you writing 'windows' programs that only run on cygwin.

Cmake is pretty awful. That is one reason I did not stick with Ogre. You have an extra build step, and at the end you still have to build things.

If you are programming in windows as your main dev it makes little sense not to use an IDE and it's very hard to do without one. If you are programming on multiple platforms I can imagine trying to do something that builds them all, using scripts or a build system. I think you are probably wasting your time though, you may be able to use cmake to immediately generate SOMETHING but it won't really be anything that I would consider using for my builds. Plus you don't necessarily have the full control of your project.

So you use Ogre or something similar and you get stuck with something crappy. You spend a ton of time editing it and though theoretically you might get it into the project usually you just wind up with a big maintenance problem.