<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 22, 2018 at 10:37 PM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>On 03/21/2018 06:01 PM, Craig Scott wrote:<br>
> I swear I asked this a while back and there was an example given<br>
<br>
</span>Maybe here:<br>
<br>
* <a href="https://gitlab.kitware.com/cmake/cmake/merge_requests/1581" rel="noreferrer" target="_blank">https://gitlab.kitware.com/cma<wbr>ke/cmake/merge_requests/1581</a></blockquote><div><br></div><div>Yes, that was it, thanks.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>> Does anyone know of a specific example scenario where an<br>
> INTERFACE IMPORTED library is the right choice over simply<br>
> INTERFACE or IMPORTED on its own?<br>
<br>
</span>A non-INTERFACE imported target needs an IMPORTED_LOCATION,<br>
so an IMPORTED target wouldn't replace an INTERFACE IMPORTED<br>
target.<br>
<br>
A plain INTERFACE library and an IMPORTED INTERFACE library are<br>
nearly identical indeed, but the scope of the name differs.<br>
<br>
IMPORTED INTERFACE libraries mostly exist for install(EXPORT)<br>
to produce from an installed/exported INTERFACE library.<br>
They can't export as a normal INTERFACE library because<br>
imported targets have visibility isolated to the directory<br>
that imports them.<br></blockquote><div><br></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Okay. So the use case is inside a package's installed config file? i.e. if a project wants to define an INTERFACE library to be provided as part of its package, it should be defining an INTERFACE IMPORTED library? And that's only needed because by convention, when someone does a find_package(), any targets created by that are usually expected to be imported targets with non-global scope, so an ordinary INTERFACE library is not quite right because it has global scope (which CMake would allow, but INTERFACE IMPORTED would be better). Following that through, the combination INTERFACE IMPORTED GLOBAL is probably of little use now, since either:</div><div class="gmail_extra"><ul><li>It doesn't need an IMPORTED_LOCATION, in which case a plain INTERFACE library is appropriate and arguably clearer/simpler.</li><li>It does need an imported location but since IMPORTED GLOBAL now supports setting interface properties, it could do the job and is also arguably clearer/simpler.<br></li></ul></div><div class="gmail_extra">Only for pre-CMake 3.11 would INTERFACE IMPORTED GLOBAL be useful, since IMPORTED GLOBAL didn't support setting interface properties before then. And it would only be useful for the case where IMPORTED_LOCATION was being set to point at a real library (otherwise just use INTERFACE on its own).</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>If there are any holes or errors in that, please let me know. Thanks.</div><div><br></div>-- <br><div class="gmail-m_273365791943045312gmail_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>