<div dir="ltr">2017-02-16 7:59 GMT+01:00 Milan Ziegler <span dir="ltr"><<a href="mailto:milan@fastmail.com" target="_blank">milan@fastmail.com</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
we are using the CMake install mechanism "install(...)" to copy all<br>
relevant files and target binaries of the product into the CMake install<br>
prefix folder, for further packaging. So far so good.<br>
<br>
We are also using several thirdparty libraries, hosting them inside our<br>
own repository and building them along with our own code, usually using<br>
add_subdirectory utilizing their native CMake buildsystem.<br>
<br>
Turns out, other developers also like the CMake install mechanism.<br>
<br>
So now the INSTALL target of our whole project also installs thirdparty<br>
components, which we do not want to deliver with our own product (think<br>
static libraries, which are already linked into our executable).<br>
<br>
After a lot of googling, here's my question: Is there a clean way to<br>
disable the install target for a subdirectory _without_ also disabling<br>
it completely for the remaining project?<br></blockquote><div><br></div><div>I would never add third party libraries to my own project in such a way mainly because:<br>- 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 time) and<br></div><div>- I would rarely/somewhat independently be changing their code.<br><br></div><div>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<br></div><div>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).<br><br></div><div>Regards,<br></div><div>Domen<br></div></div><br></div></div>