2017-02-16 7:59 GMT+01:00 Milan Ziegler <mi...@fastmail.com>:
> we are using the CMake install mechanism "install(...)" to copy all
> relevant files and target binaries of the product into the CMake install
> prefix folder, for further packaging. So far so good.
> We are also using several thirdparty libraries, hosting them inside our
> own repository and building them along with our own code, usually using
> add_subdirectory utilizing their native CMake buildsystem.
> Turns out, other developers also like the CMake install mechanism.
> So now the INSTALL target of our whole project also installs thirdparty
> components, which we do not want to deliver with our own product (think
> static libraries, which are already linked into our executable).
> After a lot of googling, here's my question: Is there a clean way to
> disable the install target for a subdirectory _without_ also disabling
> it completely for the remaining project?
I would never add third party libraries to my own project in such a way
- either my project or external project may change a variable (cache it)
and give me a head ache figuring out where the interaction went wrong (and
having to be so intimate with their build scripts is usually poor use of
- I would rarely/somewhat independently be changing their code.
I would either build external libraries (of course along with the relevant
headers) and install them somewhere on the system (treating them as a
separate project development wise) and then write find scripts for my
project to be used with "find_package()" command
or in case I'll be making some sort of an uberbuild or changing the
external code a bit more regularly (at which point I'd start to question
the design and maturity of the external dependency...) I'd go with
ExternalProject_Add() command and then install the dependencies that I'd
still like to see in my project by calling combination of
"ExternalProject_Get_Property(... binary_dir)" and "install()" commands -
external projects won't rebuild automatically if you change the code but
you can always go into the relevant subdirectory and rebuild it there (I've
found no problems doing that as usually I won't go changing multiple
external dependencies at the same time - doing that would usually indicate
poor design or invalid use of the external dependencies or my code).
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: