<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 11, 2018 at 2:28 AM, Saad Khattak <span dir="ltr"><<a href="mailto:saadrustam@gmail.com" target="_blank">saadrustam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you Craig.<div><br></div><div>>> <span style="color:rgb(33,33,33)">Imported targets are definitely more preferable though</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">Can you please elaborate on this?</span></div></div></blockquote><div><br></div><div>Variables are the old way of passing details about a target to a consuming target. It was customary to provide one variable listing the library that consuming projects would link to, then another variable would provide header search paths, maybe yet another for compiler defines, and so on. This is fragile and doesn't provide transitive dependencies (also sometimes called usage requirements), so the consuming project may then have to work out what other libraries it had to link to as well, what other header search paths it might need and so on. Imported targets address all of those problems. They act just like a regular target in the sense that they support usage requirements, so anything that links to them also gets the information about what other libraries to link against, what header search paths to add, etc. CMake automatically uses those details to augment the necessary command lines without you having to do anything. Basically you just link against the imported target and that's job done from the project's perspective. Much more robust, way easier to use.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Apr 10, 2018 at 10:23 AM Craig Scott <<a href="mailto:craig.scott@crascit.com" target="_blank">craig.scott@crascit.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 10, 2018 at 11:07 PM, Saad Khattak <span dir="ltr"><<a href="mailto:saadrustam@gmail.com" target="_blank">saadrustam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>My project is setup in such a way that I perform a FetchContent 'only if' my find_package fails.</div><div><br></div><div>This works very well until I start building different configurations. Let's say I generate and build Debug for my project. My project tries to find_package(LibA QUIET) and cannot find it. So, it performs a FetchContent(...) step, builds the dependency and my library and installs everything. This works flawlessly.</div><div><br></div><div>Now I start building a Release version with different build and install folders. Unfortunately, find_package(LibA QUIET) finds the Debug libraries and does not perform a FetchContent(...) step and in turn doesn't build the Release version of the dependent library. Consequently, the linking step fails.</div><div><br></div><div>Is there an easy way around this issue? </div><div><br></div><div>I say 'easy' because I could write some CMake scripts to search for the libraries after a successful find_package(...) and if it only finds libraries for Debug when it really wants Release, it performs a FetchContent(...). However, this could be quite fragile.</div><div><br></div><div>It would be nice if CMake has a way of knowing if an installed library, found through find_package(...) is Debug, Release, RelWithDebInfo etc.</div></div></blockquote></div><div class="gmail_extra"><br></div></div></div><div dir="ltr"><div class="gmail_extra">If the package found by find_package() is picking up a config file generated by CMake, then you can check the IMPORTED_CONFIGURATIONS property of its imported target(s). This will give you a list of configurations the package provides. Ideally, a single package should cover all relevant build types, not one package per build type. This is up to the project itself though and how it builds/installs its package. If the found package only provides variables instead of imported targets, then you'll have to work harder and go through whatever variables it provides to see if you can work out what the package can give you. Imported targets are definitely more preferable though.</div></div></blockquote></div></blockquote></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div></div></div></div></div></div></div>
</div></div>