Timeline for A slightly unconventional CMake project
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 31, 2023 at 11:40 | comment | added | Dan |
Single solution: The root CMakeLists.txt is basically the common configuration, and each project has its own CMakeLists.txt as well for project-specific stuff. This is similar to what you're suggesting, except that the projects cannot be built independently. This would be an improvement for sure. // Testing: I kept my test project separate deliberately because I wanted the tests to be as lightweight as possible. For example, the test project does not include any graphical libraries, and uses stubbed dependencies instead. So, the project configurations are quite different.
|
|
| Jul 28, 2023 at 14:18 | comment | added | Cris Luengo | @Dan Testing: You should keep unit tests inside your source files. See for example github.com/doctest/doctest . Or if you do it differently, at least keep that test target in the same CMake script as the project it’s testing. This is not a separate, independent project, and likely needs the same configuration as the main project (same compile options and so on). | |
| Jul 28, 2023 at 14:17 | comment | added | Cris Luengo | @Dan Single solution: why is there no common configuration if all these projects are related? You’re better off with an independent CMake script per project, and then a trivial one that includes those projects. —— “Every library seems to follow a different convention.” This is probably a Windows problem, sorry… —— Documentation: Yes, keep it in the source tree. But CMake doesn’t need it to build the target. You might want to define a separate documentation target, if you have a tool that builds documentation. | |
| Jul 28, 2023 at 14:12 | comment | added | Cris Luengo | @Dan Stack Exchange doesn’t really allow for a back-and-forth, unfortunately. Debug libraries: most likely the error happens in your own code, knowing what happens inside the library doesn’t help you fix your own error. Of course it’s possible for the library to have a bug, then you can to set out to debug the library if you like. But large, well-used libraries are much less likely to have a bug that your own code. | |
| Jul 28, 2023 at 8:28 | comment | added | Dan | "Documentation files should certainly not be listed as project sources." I find it helpful to have these files contained within the project for easy access inside my IDE. Is there a better way to include them? // "You don't need the same list of source files in two projects, each set of source files should constitute a single project!" The set of source files is not exactly the same; the test project includes most of the same sources, but removes some and adds some others. | |
| Jul 28, 2023 at 8:19 | comment | added | Dan |
Dependencies: I have tried providing the path explicitly but I have struggled with this in the past. Every library seems to follow a different convention and I've found it difficult to find clear documentation. Many libraries do not have an official Find* script, and there are dozens of variants online with subtle differences between them. Nonetheless, I will give this another go, because it sounds like a cleaner and more portable approach.
|
|
| Jul 28, 2023 at 8:07 | comment | added | Dan | I will list the main points here for now. (1) Yes, it is all written with Windows in mind for now. Perhaps it would need reworking for other OSes but that is a very low priority for me right now. (2) The reason for using a single CMake build for all of my projects is that I want to keep them all in the same solution. They are all related, even if they can be compiled and run independently of each other. (3) I thought this was common practice. If a library throws an error, doesn't using the debug version allow me to see where the error originated? | |
| Jul 28, 2023 at 8:00 | comment | added | Dan | Thank you for the detailed review, I will certainly take your comments onboard. Is there any way I can respond in-depth? | |
| Jul 27, 2023 at 15:58 | history | answered | Cris Luengo | CC BY-SA 4.0 |