Thinking About the Project Structure
Learn about well-defined project structure in CMake.
We'll cover the following...
It's no secret that as a project grows, it becomes harder and harder to find things in it—both in listfiles and in the source code. Therefore, it is very important to maintain the project hygiene right from the get-go.
Imagine a scenario where we need to deliver some important, time-sensitive changes, and they don't fit well in either of the two directories in our project. Now, we need to quickly push a cleanup commit that introduces more directories and another level of hierarchy for our files so that our changes can have a nice place to fit. Or (what's worse), we decide to just shove them anywhere and create a ticket to deal with the issue later.
Over the course of the year, these tickets accumulate, the technical debt grows, and so does the cost of maintaining the code. This becomes extremely troublesome when there's a crippling bug in a live system that needs a quick fix and when people unfamiliar with the code base need to introduce their changes.
So, we need a good project structure. But what does this mean?
Some golden rules
There are a few rules that we can borrow from other areas of software development (for example, system design). The project should have the following characteristics:
It should be easy to navigate and extend.
It should be self-contained—for example, project-specific files should be in the project directory and nowhere else. ...