[CMake] How to add dependency relations between libs and executable

[J Decker]

On Wed, Apr 20, 2016 at 6:21 PM, vakano <zhongle at proplussolution.com> wrote:
> Hi, Chuck,
>
> Thanks for the explanation, it is very clear now.
>
> One last question is:
>
> *folder/proj_a*
> CMakeLists.txt:
> add_executable(A main.cpp)
> target_link_libraries(A B C)
>
> *folder/proj_b*
> CMakeLists.txt:
> project(proj_b)
> add_library(B proj_b.cpp)
>
> in your proj_a example, when target_link_librairies invoke Lib B directly
> which generated in another
>
> project b, how does proj_a recognize it, I think the reason is proj_a, b, c
> are all the sub directories of
>
> project root, if no root layer, B can not be invoked in proj_a, right?
>
> Thanks,
> vakano
>

Targets are global.  ... Add_library( ${target_name} ${sources} )
later becomes $<TARGET_XXX> as generator expressions also...

add_executable( /*target_name*/ [WIN32 CONSOLE (default console)] ... )
add_library( /*target_name */  [STATIC or SHARED (default STATIC... ] ... )

actually there's a way to control what the defaults are if you don't
specify anything.. but that tends to apply to the whole make system so
if you just add_subdirectory( ../bullet3  bullet3 ) for instance it
might end up doing things like appending 'd' to output names :)  (it
doesn't anymore)


Sub-projects can also be built individually by going into theiry
direcotry and doing a make (selecting the target and building in a
gui) and it will build everything it's related to.

>
>
> Chuck Atkins wrote
>>> So for this parallel project structure, an upper level cmakelist used to
>>> organize and setup relationship with lib A, B, C right?
>>>
>>
>> Correct.  The top level CMakeLists.txt lets A B and C all build under a
>> single configuration.
>>
>>
>> One more question is, if use the upper level cmake list, lib_B , lib_C can
>>> be invoked directly without import in proj_a?
>>>
>>
>> If you configure the top level project, you can always invoke make on only
>> the B or C targets via "make A" or "make B".  However, by having the
>> "project' command in the CMakeLists.txt for proj_b and proj_c, then those
>> can also be treated as fully independent projects of their own, meaning
>> they can either be configured by themselves or as a part of the top-level.
>>
>> - Chuck
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>
>
>
>
>
> --
> View this message in context: http://cmake.3232098.n2.nabble.com/How-to-add-dependency-relations-between-libs-and-executable-tp7593264p7593305.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake