[CMake] Removing Transitively Inherited Properties
What is the recommended way of removing transitively inherited attributes for a target. Example: target_link_libraries(A PRIVATE B) target_compile_options(B PUBLIC -Werror) How should the -Werror option be removed from target A. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] modularizing, specifying dependencies in a project
This works.
Have pushed changes to the repo here:
https://github.com/vargheseg/test
Thank you
On Wed, Jan 3, 2018 at 8:16 PM, Robert Maynard
<robert.mayn...@kitware.com> wrote:
> You will want to use add_subdirectory instead of include in the root
> CMakeLists.txt and remove all include statements from ModA and ModB
>
> It total the changes needed to get everything to work are:
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index e611a37..b6968c1 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -1,8 +1,9 @@
> cmake_minimum_required(VERSION 3.0)
> project(test_project)
>
> -include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
> -include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)
> +add_subdirectory(ModA)
> +add_subdirectory(ModB)
> +add_subdirectory(ModC)
>
> add_executable(main main.cpp)
> target_link_libraries(main
> diff --git a/ModA/CMakeLists.txt b/ModA/CMakeLists.txt
> index 87128d8..4931be6 100644
> --- a/ModA/CMakeLists.txt
> +++ b/ModA/CMakeLists.txt
> @@ -1,5 +1,4 @@
> -include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
> -add_library(ModA $CMAKE_CURRENT_LIST_DIR}/a.cpp)
> +add_library(ModA a.cpp)
> target_link_libraries(ModA
> PRIVATE
> ModC)
> diff --git a/ModB/CMakeLists.txt b/ModB/CMakeLists.txt
> index 3a31be9..7f83856 100644
> --- a/ModB/CMakeLists.txt
> +++ b/ModB/CMakeLists.txt
> @@ -1,4 +1,3 @@
> -include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
>
> add_library(ModB b.cpp)
> target_link_libraries(ModB
>
> On Wed, Jan 3, 2018 at 1:46 PM, Geogin Varghese <geo...@gmail.com> wrote:
>> Hello,
>>
>> Recently came across these presentations on cmake:
>>
>> Using Modern CMake Patterns to Enforce a Good Modular Design
>> (https://www.youtube.com/watch?v=bsXLMQ6WgIk)
>> Effective CMake
>> (https://www.youtube.com/watch?v=eC9-iRN2b04)
>>
>> They encourage using target_* command variants for scripting
>> CMakeLists.txt.
>>
>> What would be the recommended way of writing build scripts for a
>> repository structured as below. The application is compiled from three
>> modules with a dependency among the modules as in the ascii diagram.
>>
>> Is it possible to distribute compile info, such that each submodule has
>> a CMakeLists.txt that describes sources, include and link dependencies needed
>> to compile that module.
>>
>> ---
>> .
>> ├── main.cpp
>> ├── ModA
>> ├── ModB
>> ├── ModC
>>
>> Dependency relation:
>>
>>++
>> +->+main.cpp+<-+
>> | ++ |
>> | |
>> | |
>> | |
>> ++++
>> |ModA||ModB|
>> ++++
>> ^ ^
>> | |
>> |++|
>> ++ModC++
>> ++
>>
>> ModA <- ModC: Module A
>> depends on Module C
>> ---
>>
>> My naive effort to do this can be found here:
>> https://github.com/vargheseg/test
>>
>> The problem I run into is with describing the dependency relation
>> between ModA, ModB and ModC.
>>
>> Details:
>> .
>> ├── CMakeLists.txt
>> ├── main.cpp
>> ├── ModA
>> │ ├── a.cpp
>> │ └── CMakeLists.txt
>> ├── ModB
>> │ ├── b.cpp
>> │ └── CMakeLists.txt
>> ├── ModC
>> │ ├── c.cpp
>> │ └── CMakeLists.txt
>>
>> - CMakeLists.txt in the child directories describe compilation
>> information for that directory.
>> - The top level directory includes the CMakeLists.txt from
>> subdirectories.
>> - Cmake buildfile generation fails because the way I set things up; the
>> top level CMakeLists.txt ends up including ModC/CMakeLists.txt twice.
>>
>> ---
>> CMakeLists.txt
>> ---
>> cmake_minimum_required(VERSION 3.0)
>> project(test_project)
>>
>> include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
>> include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)
>>
>> add_executable(main main.cpp)
>> target_link_libraries(main PRIVATE ModA ModB)
>>
>>
>> ---
>> ModA/CMakeLists.txt
>> ---
>> include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
>> add_library(ModA $CMAKE_CURRENT_LIST_DIR}/a.cpp)
>> target_link_libraries(ModA PRIVATE ModC)
>>
>>
>> ---
>> ModB/CMakeLists.txt
>> ---
>> include(${CMAKE_CURRENT
[CMake] modularizing, specifying dependencies in a project
Hello,
Recently came across these presentations on cmake:
Using Modern CMake Patterns to Enforce a Good Modular Design
(https://www.youtube.com/watch?v=bsXLMQ6WgIk)
Effective CMake
(https://www.youtube.com/watch?v=eC9-iRN2b04)
They encourage using target_* command variants for scripting
CMakeLists.txt.
What would be the recommended way of writing build scripts for a
repository structured as below. The application is compiled from three
modules with a dependency among the modules as in the ascii diagram.
Is it possible to distribute compile info, such that each submodule has
a CMakeLists.txt that describes sources, include and link dependencies needed
to compile that module.
---
.
├── main.cpp
├── ModA
├── ModB
├── ModC
Dependency relation:
++
+->+main.cpp+<-+
| ++ |
| |
| |
| |
++++
|ModA||ModB|
++++
^ ^
| |
|++|
++ModC++
++
ModA <- ModC: Module A
depends on Module C
---
My naive effort to do this can be found here:
https://github.com/vargheseg/test
The problem I run into is with describing the dependency relation
between ModA, ModB and ModC.
Details:
.
├── CMakeLists.txt
├── main.cpp
├── ModA
│ ├── a.cpp
│ └── CMakeLists.txt
├── ModB
│ ├── b.cpp
│ └── CMakeLists.txt
├── ModC
│ ├── c.cpp
│ └── CMakeLists.txt
- CMakeLists.txt in the child directories describe compilation
information for that directory.
- The top level directory includes the CMakeLists.txt from
subdirectories.
- Cmake buildfile generation fails because the way I set things up; the
top level CMakeLists.txt ends up including ModC/CMakeLists.txt twice.
---
CMakeLists.txt
---
cmake_minimum_required(VERSION 3.0)
project(test_project)
include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE ModA ModB)
---
ModA/CMakeLists.txt
---
include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
add_library(ModA $CMAKE_CURRENT_LIST_DIR}/a.cpp)
target_link_libraries(ModA PRIVATE ModC)
---
ModB/CMakeLists.txt
---
include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
add_library(ModB b.cpp)
target_link_libraries(ModB
PRIVATE
ModC)
Is this way of structuring a project a supported use case?
--
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:
https://cmake.org/mailman/listinfo/cmake
