C++ desktop application development doesn't really lend itself to this approach, per-se, but we do follow a somewhat similar process.
Our build system is a combination of CMake and Makefiles. This means that if someone knows what they're doing, they still have total control over the build process. Meanwhile, the rest of us don't have to bother with it, because 99% of it is automated.
So, for most people:
Make sure you have a C++ compiler and CMake installed.
Clone the repository for whichever of our projects you are building.
Clone our dependency repositories in the same directory as the one you cloned in Step 2. That's key to the magics.
Run 'make ready' in each repository, working your way up the dependency chain, as outlined in the main project's README.md and BUILDING.md files.
On the last one, you can run 'make ready' for the default build, or 'make tester' if you want to test it out instead.
How does that work, exactly? Pretty simple.
First, we keep a repository of all our dependencies (libdeps), containing the latest version we've tested against, so you can either use that for the easy way, or bring your own, which is a little harder, but gives you more control. We provide a template for the very simple .config file, which is used to tell the build system for the given repository where to find its dependencies.
Second, we structured the folders so that CMake runs an out-of-place build in a dedicated temporary folder within the source directory! This means that we can write custom Makefiles in the parent directories, including the repository root, for executing the most common CMake commands. That little bit of witchery has been called both "brilliant" and "convoluted," but either way, I can't take credit for it. I learned the trick from CPGF's build system. Love it or hate it, it really is the best of both worlds; if you don't want to run CMake directly, make ready does it for you!
Those short instructions, including where to get each dependency, is listed in the BUILDING.md file in each repository.
As a side effect, nearly all of the build system's code never needs to be altered. There are two specific places in CMakeLists.txt that have to be changed as the project does - one for new dependencies, and one for new files within the project. Each change is only 2-3 lines each, and always follows the same pattern.
Of course, I do have the entire system documented in painstaking detail elsewhere, for ongoing maintenance, but I've had to modify it all of...once since I devised it? It's pretty neat.
The cool part is, it has worked on every system we've tried it on, flawlessly, every time. Even our CI, Jenkins, loves it. (We haven't yet added Windows support. We CAN, we just don't care enough about that platform yet.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
C++ desktop application development doesn't really lend itself to this approach, per-se, but we do follow a somewhat similar process.
Our build system is a combination of CMake and Makefiles. This means that if someone knows what they're doing, they still have total control over the build process. Meanwhile, the rest of us don't have to bother with it, because 99% of it is automated.
So, for most people:
Make sure you have a C++ compiler and CMake installed.
Clone the repository for whichever of our projects you are building.
Clone our dependency repositories in the same directory as the one you cloned in Step 2. That's key to the magics.
Run 'make ready' in each repository, working your way up the dependency chain, as outlined in the main project's
README.mdandBUILDING.mdfiles.On the last one, you can run 'make ready' for the default build, or 'make tester' if you want to test it out instead.
How does that work, exactly? Pretty simple.
First, we keep a repository of all our dependencies (
libdeps), containing the latest version we've tested against, so you can either use that for the easy way, or bring your own, which is a little harder, but gives you more control. We provide a template for the very simple.configfile, which is used to tell the build system for the given repository where to find its dependencies.Second, we structured the folders so that CMake runs an out-of-place build in a dedicated temporary folder within the source directory! This means that we can write custom Makefiles in the parent directories, including the repository root, for executing the most common CMake commands. That little bit of witchery has been called both "brilliant" and "convoluted," but either way, I can't take credit for it. I learned the trick from CPGF's build system. Love it or hate it, it really is the best of both worlds; if you don't want to run CMake directly,
make readydoes it for you!Those short instructions, including where to get each dependency, is listed in the
BUILDING.mdfile in each repository.As a side effect, nearly all of the build system's code never needs to be altered. There are two specific places in
CMakeLists.txtthat have to be changed as the project does - one for new dependencies, and one for new files within the project. Each change is only 2-3 lines each, and always follows the same pattern.Of course, I do have the entire system documented in painstaking detail elsewhere, for ongoing maintenance, but I've had to modify it all of...once since I devised it? It's pretty neat.
The cool part is, it has worked on every system we've tried it on, flawlessly, every time. Even our CI, Jenkins, loves it. (We haven't yet added Windows support. We CAN, we just don't care enough about that platform yet.)