<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
cmake, the old top layer project is proj_a, which at the same layer with<br>
proj_b and proj_c, if I add an extra top layer as the root you mentioned, </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> the generated make file structure
will be changed, top layer make file </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> will be root instead of proj_a.<br>
<br>
Is there any way to add the dependency at proj_a level?<br></blockquote><div><br></div>If you want proj_a, proj_b, and proj_c to all be built by the same make command, then it makes sense to have a top level organization that encompasses them all. Also, if proj_a, proj_b and proj_c don't make sense on their own and only when paired with each-other, then I would take the "project(...)" command out of each of them and only leave the top level. Basically, anything that has a project(...) command can be configured and built all on it's own without the rest of the tree. In this case, it may make sense to keep b and c as independent projects but a as not since it needs b and c. So for example, similar to Anatoly's example:<br><span style="font-family:monospace,monospace"><br><b>folder</b><br>
CMakeLists.txt:<br>
project(root)<br>
add_subdirectory(proj_b)<br>
add_subdirectory(proj_c)<br>
add_subdirectory(proj_a)<br>
<br>
<b>folder/proj_a</b><br>
CMakeLists.txt:<br>
add_executable(<b>A </b>main.cpp)<br>
target_link_libraries(<b>A B C</b>)<br>
<br>
<b>folder/proj_b</b><br>
CMakeLists.txt:<br>
project(proj_b)<br>
add_library(B proj_b.cpp)<br>
<br>
<b>folder/proj_c</b><br>
CMakeLists.txt:<br>
project(proj_c)<br>
add_library(<b>C </b>proj_c.cpp)</span><br>
<br><br>
</div><div class="gmail_quote">With this structure, you can configure and build just project b or c:<br><br></div><div class="gmail_quote"><span style="font-family:monospace,monospace">$ mkdir build_c<br></span></div><div class="gmail_quote"><span style="font-family:monospace,monospace">$ cd build_c<br></span></div><div class="gmail_quote"><span style="font-family:monospace,monospace">$ cmake /path/to/folder/proj_c<br>...<br></span></div><div class="gmail_quote"><span style="font-family:monospace,monospace">$ make<br>...</span><br><br></div><div class="gmail_quote">You end up with libC.a . Similarly, you could do that for proj_b and get libB.a. Or, if you configure the top level project instead:<br><span style="font-family:monospace,monospace"><br></span><div class="gmail_quote"><span style="font-family:monospace,monospace">$ mkdir build_all<br></span></div><div class="gmail_quote"><span style="font-family:monospace,monospace">$ cd build_all<br></span></div><div class="gmail_quote"><span style="font-family:monospace,monospace">$ cmake /path/to/folder<br>...<br></span></div><span style="font-family:monospace,monospace">$ make<br>Scanning dependencies of target B<br>[ 16%] Building CXX object proj_b/CMakeFiles/B.dir/proj_b.o<br>[ 33%] Linking CXX static library libB.a<br>[ 33%] Built target B<br>Scanning dependencies of target C<br>[ 50%] Building CXX object proj_c/CMakeFiles/C.dir/proj_c.o<br>[ 66%] Linking CXX static library libC.a<br>[ 66%] Built target C<br>Scanning dependencies of target A<br>[ 83%] Building CXX object proj_a/CMakeFiles/A.dir/main.o<br>[100%] Linking CXX executable A<br>[100%] Built target A<br>$</span><br></div><div class="gmail_quote">
<br></div><div class="gmail_quote">You end up with proj_b/libB.a, proj_c/libC.a, and proj_a/A which is linked with libB.a and libC.a. You can also do a parallel make with make -j(whatever) adn the generated dependencies will make sure that targets and individual files are built in the right order. Technically speaking, you don't *need* to have a CMakeLists.txt at each level and you could put it all in to one top level CMakeLists.txt but it's generally considered poor CMake code to do so. A good rule of thumb is to have a CMakeLsits.txt file at each level that a target (i.e. a library or executable) is built and a top level CMakeLists.txt to tie it all together. This is the same sort of approach you see with autoconf where it's typical to have a Makefile.am at each level.<br></div><div class="gmail_quote"><br></div></div></div>