That is roughly what I am saying. In my head you had a layout that looked
So while it is tedious to have module_A explicitly add tests_A it would be
a possible solution. The problem is one of graph building. Currently the
CMake 'all' graph properly represents building the active module and all
dependencies it needs. Separately you have a pool of smaller graphs that
represent all tests and targets that are from sub-directories that had
EXCLUDE_FROM_ALL applied. Nothing is quickly coming to me that will allow
you to add more components to the 'all' graph after the fact.
On Thu, May 17, 2018 at 6:19 AM Job Noorman <j...@noorman.info> wrote:
> 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:
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
Follow this link to subscribe/unsubscribe: