4 ms·

This is a really weird way of doing things. You can just add_subdirectory from the top level all the way down as intended. Then if you only want to build A, you

This is a really weird way of doing things. You can just add_subdirectory from the top level all the way down as intended. Then if you only want to build A, you just do "make A" instead of parameterless "make". Am I missing something that makes this approach bad? IMO this is the idiomatic way to do it.

BeeOnRope 6y ago
How would you lay out the directory structure for the diamond dependency shape discussed in the post? Specifically, where would "base" live?
- sjburt 6y ago
  root/ base/ a/ b/ As long as root has a CMakeLists.txt and includes base, a, and b, cmake will figure it out. After the build tree has been built with cmake, you can even run make from the build/root/a/ directory and base/ and a/ will be built. The author, for some reason, does not want a cmakelists.txt in root/ and wants to run cmake from a or b alone so they have to use a more convoluted approach.
  - qznc 6y ago
    One reason against the CMakeLists.txt at the root: When you generate a Visual Studio "solution", every target becomes a "project". At work this results in a few hundred projects and VS gets slow. Someone build a Python script to trim it down. This is treating symptoms instead of root causes and adds accidental complexity. Of course, the root CMake also needs to parse all sub directories which requires time. However, this has not been a big problem in practice so far. Only on the "annoying" level.
    - wheybags 6y ago
      That sounds like you've just got too many projects. Why not merge them? You also save wasted time on linking static libraries (at least on Linux this is significant, dunno about windows).
ihnorton 6y ago
Many (if not most) libraries don’t work correctly with add_subdirectory.
- wheybags 6y ago
  My normal strategy is too just dump most of their build system and remake it myself in cmake. Even if they use cmake, I often end up commenting out most of it. If you keep things super simple in your cmake, it all works very well. Writing super simple cmake is also pretty easy, as well. Regardless, this article was talking about internal dependencies, not external ones.
junon 6y ago
This doesn't work all the time. The problem is that there's a difference with how targets are built up vs. how find_package() specifies you should detect system deps, and they're inherently incompatible with each other.
- wheybags 6y ago
  This is talking about internal dependencies though, not system ones. That said, my strategy for system deps is to just not use them and vendor everything I can, rewriting their build system in cmake if I have to.
  - junon 6y ago
    Yes, exactly. It doesn't always work like you'd expect. Custom find modules can use custom variables and thus you have to define them manually in every case. This macro gets you half the way there, at least.

BeeOnRope 6y ago

How would you lay out the directory structure for the diamond dependency shape discussed in the post? Specifically, where would "base" live?

sjburt 6y ago
root/ base/ a/ b/ As long as root has a CMakeLists.txt and includes base, a, and b, cmake will figure it out. After the build tree has been built with cmake, you can even run make from the build/root/a/ directory and base/ and a/ will be built. The author, for some reason, does not want a cmakelists.txt in root/ and wants to run cmake from a or b alone so they have to use a more convoluted approach.
- qznc 6y ago
  One reason against the CMakeLists.txt at the root: When you generate a Visual Studio "solution", every target becomes a "project". At work this results in a few hundred projects and VS gets slow. Someone build a Python script to trim it down. This is treating symptoms instead of root causes and adds accidental complexity. Of course, the root CMake also needs to parse all sub directories which requires time. However, this has not been a big problem in practice so far. Only on the "annoying" level.
  - wheybags 6y ago
    That sounds like you've just got too many projects. Why not merge them? You also save wasted time on linking static libraries (at least on Linux this is significant, dunno about windows).

ihnorton 6y ago

Many (if not most) libraries don’t work correctly with add_subdirectory.

wheybags 6y ago
My normal strategy is too just dump most of their build system and remake it myself in cmake. Even if they use cmake, I often end up commenting out most of it. If you keep things super simple in your cmake, it all works very well. Writing super simple cmake is also pretty easy, as well. Regardless, this article was talking about internal dependencies, not external ones.

junon 6y ago

This doesn't work all the time. The problem is that there's a difference with how targets are built up vs. how find_package() specifies you should detect system deps, and they're inherently incompatible with each other.

wheybags 6y ago
This is talking about internal dependencies though, not system ones. That said, my strategy for system deps is to just not use them and vendor everything I can, rewriting their build system in cmake if I have to.
- junon 6y ago
  Yes, exactly. It doesn't always work like you'd expect. Custom find modules can use custom variables and thus you have to define them manually in every case. This macro gets you half the way there, at least.