Modern Development Environment for C++
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 .
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.