I'm not sure I completely understand what you mean but I think your
suggestion would be to list *all* needed subdirectories in the active
project. This is not what a want. The active project simply lists its
*direct* dependencies (via target_link_libraries) and CMake then figures
out all the needed transitive dependencies.
Please correct me if i missed your point :-)
On 15/05/18 23:29, Robert Maynard wrote:
Have you thought about not doing anything in the root CMakeLists for
your testing directories but instead inside the active project you use
add_subdirectory ( it supports relative paths to handle directories
not physically nested inside it ).
On Wed, May 9, 2018 at 8:56 AM Job Noorman <j...@noorman.info
<mailto:j...@noorman.info>> wrote:
Hi all,
We have a large codebase consisting of 200+ modules. Each module is
defined in its own subdirectory and compiled as a static library.
These modules are not final products on their own but are combined to
create "projects". We have about 15 projects that all use a subset of
the modules to implement their functionality. The projects are
independent in the sense that they cannot be built together; when
running cmake, we select the project to build.
To ensure that only the modules that are needed by the selected
project
are built, we took the following approach: all modules have a common
root directory which is included using add_subdirectory with the
EXCLUDE_FROM_ALL flag. Then, the current project's root directory is
added without this flag. This ensures that the targets defined by the
project and the modules that they need (but no other) are added to
the
build system. This works very well and is much nicer than having to
define options for all optional modules to be able to disable them.
There is one catch, however: each module defines an executable
that runs
its unit tests. What should happen is that if a module is built by a
project, its unit tests are also built. However, there seems to be no
way to define this relationship in CMake. What we would like to
express
is that "if library A is built, then executable ATest should also be
built". Since ATest obviously links against A, we cannot use
add_dependencies(A ATest) since this creates a circular dependency
between an executable and a library.
Note that the "option" approach briefly mentioned above would
allow us
to express this but this would be completely unwieldy in our case.
Is there currently a way in CMake to express this relation between a
library and an executable?
If not, would the following suggestion make sense?: A target property
"INTERFACE_DEPENDENCIES" could be added that would set the
MANUALLY_ADDED_DEPENDENCIES target property of dependents. Setting
this
property on A with ATest as value would then solve my problem
(note that
I proposed adding this property for a different use case here:
https://gitlab.kitware.com/cmake/cmake/issues/14633).
Regards,
Job
--
Powered by www.kitware.com <http://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
--
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
