<div dir="ltr">Ping?<div><br></div><div>I'd like to file a bug but I don't know what is the intended behavior:<div>1. Should binary_dir work even when no target?<br><div>2. Should CMake warn/error that binary_dir is not supported unless targets are used?</div><div><br></div></div><div>Marc</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 4 juin 2019 à 12:05, Marc Herbert <<a href="mailto:marc.herbert@gmail.com">marc.herbert@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">tl;dr: should there be at least one target per CMakeLists.txt?<br><br><a href="https://cmake.org/cmake/help/v3.14/command/add_subdirectory.html" target="_blank">https://cmake.org/cmake/help/v3.14/command/add_subdirectory.html</a><br>> add_subdirectory(source_dir [binary_dir] )<br>> "The binary_dir specifies the directory in which to place the output files. [...] If binary_dir is not specified, the value of source_dir, before expanding any relative path, will be used (the typical usage)."<br><br>I found this part of the documentation to be correct ONLY when the subdirectory defines and uses its own "sub-"target(s). If the subdirectory refers to higher main targets instead then binary_dir/ is just a decoy: the subdirectory build happens elsewhere. binary_dir is a decoy whether it's explicit or default. It exists but there are only totally generic and unused files there.<br><br>Example:<br><br>mainsrc/<br>├── CMakeLists.txt<br>├── inmodule<br>│   ├── CMakeLists.txt<br>│   ├── infile.c<br>└── mainfile.c<br><br><br># mainsrc/CMakeLists.txt<br>add_executable(mainexe mainfile.c)<br>add_subdirectory(inmodule [ decoy_binary_dir ] )<br><br># mainsrc/inmodule/CMakeLists.txt<br>target_sources(mainexe PRIVATE infile.c) # <= direct reference, no sub-target<br><br><br>cmake -GNinja -B build -S mainsrc && ninja -C build<br><br>build<br>├── CMakeFiles<br>│   ├──<br>│   ├── mainexe.dir<br>│   │   ├──<br>│   │   ├──<br>│   │   ├── inmodule       <= ACTUAL binary_dir!<br>│   │   │   └── infile.c.o<br>│   │   ├── mainfile.c.o<br>│   │   ├──<br>│   │   :<br>│   ├──<br>│   :<br>├── inmodule       <= decoy with unused, boilerplate files and no reference to any code<br>│   ├── CMakeFiles/<br>│   ├── cmake_install.cmake<br><br><br>The midly irritating part is that cmake complains about the lack of a binary_dir argument if the module is an _out-of-tree_ subdirectory:<br><br>CMake Error at CMakeLists.txt:5 (add_subdirectory):<br>  add_subdirectory not given a binary directory but the given source<br>  directory "~/cmake-test/outmodule" is not a subdirectory of<br>  "~/cmake-test/maindir".  When specifying an out-of-tree source<br>  a binary directory must be explicitly specified.<br><br>That request makes sense of course except... when given that binary_dir argument it requested, it's still becomes a decoy as described above.<br>This is the actual (and funny) binary_dir /in this out-of-tree case:<br>build<br>├── CMakeFiles<br>│   ├── mainexe.dir<br>│   │   └── home<br>│   │       └── joe<br>│   │           └── cmake-test<br>│   │               └── outmodule<br>│   │                   └── outfile.c.o<br><br><br><br>Reproduced with cmake version 3.14.4. No difference between make and ninja.<br><br>Researching the interwebs most people, tutorials and other documents seem to assume (at least) one target per CMakeLists.txt. Should such a recommendation be made more official to avoid the sort of confusion above? Could this recommendation avoid other, unrelated problems I haven't experienced? Yet?<br><br>Marc<br></div>
</blockquote></div>