[CMake] graphviz missing dependencies when target spans multiple subfolders

[Craig Scott]

On Sat, Oct 26, 2019 at 9:11 AM Rich von Lehe <rhvonlehe at gmail.com> wrote:

> I am using CMake 3.15.1.  Having found out about some of the changes with
> 3.13, I've started to take advantage of using 'add_subdirectory()' in
> certain cases when a module is large and spans multiple source folders.
>
> For instance:
>
> ModuleA/CMakeLists.txt:
> ------------------------------------
> add_library(moduleA STATIC "")
>
> add_subdirectory(sub1)
> add_subdirectory(sub2)
> ------------------------------------------
>
> sub1/CMakeLists.txt
> ------------------------------
> target_include_directories(moduleA PUBLIC .)
> target_sources(moduleA
>    PRIVATE
>         src1.cpp
>         src2.cpp
>     )
>
> target_link_libraries(moduleA
>     PRIVATE
>         Qt5::Widgets
>         Qt5::Qml
>         moduleB
>     )
>
> sub2/CMakeLists.txt
> ------------------------------
> target_include_directories(moduleA PUBLIC .)
> target_sources(moduleA
>     PRIVATE
>         src1.cpp
>         src2.cpp
>     )
>
> target_link_libraries(moduleA
>     PRIVATE
>         Qt5::Quick
>         moduleC
>     )
> -----------------------------------
>
> I run cmake --graphviz=project.dot .
>
> From this, two of the files that comes out are project.dot.moduleA and
> project.dot.moduleA.dependers.
>
> The former is only this:
> digraph "GG" {
> node [
>   fontsize = "12"
> ];
>     "node190" [ label="moduleA" shape="diamond"];
> }
>
> There is no mention of the Qt5 or other module dependencies.
>
>
> Other modules with dependencies but without the hierarchy introduced with
> add_subdirectory() seem to be just fine and include their respective
> dependencies in their project.dot.moduleX files.
>
> Is this a bug or am I misusing add_subdirectory() here?  With the
> exception of the graphviz output, everything builds and runs as expected
> with my setup.
>

The structure of your project looks fine, it's probably a bug in the
graphviz handling. There has been a bit of activity around improving that
recently, so it's possible that it has either been broken recently or has
been fixed on master already. Can you please try a few earlier CMake
versions and see if the problem has always been there? If it looks like a
recently introduced regression, please also try a nightly build of the
latest master (or build CMake from sources yourself if you're happy to do
that). If the bug is still there on master, I suggest you file a bug report.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20191026/bbe85806/attachment-0001.html>