Modern Development Environment for C++
DavidZemon
Posts: 2,973
I wrote a pair of blog articles over the last year, based on experience I gained at my previous employer between 2017 and 2019, about setting up a modern development environment for C/C++. When I arrived at that company, they had some of the best engineers I've had the pleasure of working with, but they were using tools that were... not the best. Introducing that team to some modern tools while incorporating their existing old tools (old stuff like GCC or valgrind, which still work great) was a real pleasure, and one of the highlights of that job for me. It took every bit of the three years that I worked there to work out the kinks, and then I had to polish it a bit more during the course of writing these two articles, but the end result is fantastic. The stack encourages consistency where it matters - like the build system, folder structure, and unit test framework, but allows flexibility where appropriate - like IDE. The guy that likes Emacs was very happy to use this setup because he gained everything that CMake and Conan had to offer without needing to learn a new text editor. The manager was very happy that we could slowly transition to Conan because the CMake scripts were written in such a way as to not be dependent on Conan - the firmware could still be built without Conan even being installed. But... once we all had confidence in Conan, a switch was flipped and we started building firmware from pre-built binaries stored in our artifact repository - much faster!
Anyway, in case you couldn't tell, I'm very proud of all the work that went into figuring out how to make all of these tools play well together. I'm not saying you should always use this entire stack of tools. For most hobby projects, it would be overkill. But then... C++ is major overkill for most hobby projects, and you should just be using Python anyway 
.
So, without further ado, I present to you Part 1 and Part 2 of the Modern Development Environment for C++. Professional engineers may learn a thing or two from this 
.
I do think a Part 3 would be appropriate. I imagine anyone who reads these two blog articles and wants to try using jumpstart for a professional project is going to have a lot of questions. That's probably what part 3 should be: answering first-time use questions. An FAQ, basically? Let me know your thoughts on this, if you wouldn't mind. I'd love to know what you think I should cover in part 3.
Comments
In my experience, CMake is a very "works on my machine" tool aka a torture device for people trying to build the project. I've literally never been able to just clone and build a CMake project. Always some different nonsense that either requires passing some build variable (like when it really wants to use cc65's zlib) or god forbid edit the build script, wherein one is confronted with a horrific custom language that exists only to cause pain. Like, why not use any of the trillion existant scripting languages? And even if that worked there's a good chance the generated makefile doesn't work (though I think that's mostly a Windows-specific issue).
In other words, use CMake if you want to look cool for open-sourcing a project but don't want anyone to ever actually build it themselves.
Sorry for the unpromted rant, but trying to get obnoxious build systems going is one of those things that literally drain the life from my body.
I'm very sorry to hear that, @Wuerfel_21. I've introduced CMake into two teams, one at each of two different companies, and both teams unanimously loved it. I won't say it's perfect - the fact that they felt the need to create their own scripting language is, without a doubt, one of the worst parts - but I've certainly not seen anyone else experience that level of problems before.
But... it sounds like you were working from Windows... and Windows is a horrendous mess when trying to build with CMake/Make/GCC/etc, or pretty much any command-line tool. All of my industry C/C++ experience has been 100% on Linux, with just a couple folks being die-hard Windows guys that needed just enough Windows support to be able to cross-compile, and we were able to get that working for them. Conan helped a lot there.
From a Parallax standpoint, I tried for years to get an easy-to-use Windows setup for PropWare, and never felt like it was really there. Technically, PropWare should be cross-platform... but then reality hits, and you realize that when something is developed entirely on one system (Linux, in my case), it is very difficult to get it working on another. Even when all of the individual tools in the project are cross platform.
Yeah, I think part of the reason is that I've not used it for any projects of my own, only when working on projects that already use it. I always got it working eventually, so it's not been that bad. And the sample size is like, 6 projects or something.
I heard there's a great and free CMake course out there: https://davidzemon.github.io/LearnCMake/
Rumor has it the instructor is top-notch.