There is one difference that I thought of immediately, and I tested it - an INTERFACE target can be installed/exported, but an INTERFACE IMPORTED target cannot be installed/exported because CMake considers it to not be in the build/source directory. I'm sure there are other internal differences due to the fact that imported targets aren't considered to be inside the build or source directories.
I think the main takeaway is that "INTERFACE IMPORTED" is not actually a different kind of target, it is just a target which is both INTERFACE and IMPORTED. Why not allow all four combinations of INTERFACE and IMPORTED? On Tue, Jul 5, 2016 at 7:35 PM, Ted Middleton <middleton....@gmail.com> wrote: > Ack - sorry. s/INTERFACE_LINK_LIBRARIES/IMPORTED_LOCATION/cg. > INTERFACE_LINK_LIBRARIES I guess would be a completely valid property to set > on an add_library(foo INTERFACE) target. But IMPORTED_LOCATION wouldn't, > right? > > "INTERFACE IMPORTED would then mean there is no compiled > binary to be linked against, just as INTERFACE alone means there are > no sources to create said binary from" > > Is there a difference between them, then? If neither produce an actual build > rule, and neither can point to a .lib/.so/.dll/.a/.dylib, are they not > exactly the same thing? The documentation says that add_library(foo > INTERFACE IMPORTED) creates an /imported target/, but the explanation of > what exactly this is is ... confusing? Based on the description of what an > /imported target/ is, I would think that it is the same thing that > add_library(foo <STATIC|SHARED> IMPORTED) produces? > > > > On Tue, Jul 5, 2016 at 4:09 PM, Nicholas Braden <nicholas11bra...@gmail.com> > wrote: >> >> From what I understand, interface libraries just don't have sources or >> build results. INTERFACE IMPORTED would then mean there is no compiled >> binary to be linked against, just as INTERFACE alone means there are >> no sources to create said binary from. At least, that is my >> understanding. >> >> > My understanding of this is that setting INTERFACE_LINK_LIBRARIES on a >> > target like this would be an error? >> >> Why can't a header-only library link to non-header-only libraries? >> >> On Tue, Jul 5, 2016 at 5:17 PM, Ted Middleton <middleton....@gmail.com> >> wrote: >> > I'm looking at the documentation for add_library(), and I'm really >> > confused >> > about the distinction between add_library(foo INTERFACE) vs >> > add_library(foo >> > INTERFACE IMPORTED) vs add_library(foo <SHARED|STATIC> IMPORTED). >> > >> > Correct me if I'm wrong (and I probably am), but add_library(foo >> > INTERFACE) >> > is for propagating properties like INTERFACE_INCLUDE_DIRECTORIES to >> > other >> > targets using target_link_libraries(), so that header-only libraries can >> > be >> > consumed by other targets conveniently. My understanding of this is that >> > setting INTERFACE_LINK_LIBRARIES on a target like this would be an >> > error? >> > >> > And add_library(foo SHARED IMPORTED) would be to create a target object >> > for >> > a pre-existing library (like a platform lib or something) for which >> > cmake is >> > not supposed to try to create an actual "call the compiler and >> > linkeditor or >> > archiver" build rule. This still boils down to mostly propagating >> > properties, no? Except now some of those properties can be things like >> > INTERFACE_LINK_LIBRARIES? >> > >> > So can anyone tell me what add_library(foo INTERFACE IMPORTED) is? The >> > documentation says, >> > >> > "An INTERFACE Imported Target may also be created with this signature. >> > An >> > IMPORTED library target references a library defined outside the >> > project. >> > The target name has scope in the directory in which it is created and >> > below, >> > but the GLOBAL option extends visibility. It may be referenced like any >> > target built within the project. IMPORTED libraries are useful for >> > convenient reference from commands like target_link_libraries()." >> > >> > That description is what I thought add_library(foo <SHARED|STATIC> >> > IMPORTED) >> > was for? >> > >> > >> > >> > -- >> > >> > Powered by 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: >> > http://public.kitware.com/mailman/listinfo/cmake > > -- Powered by 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: http://public.kitware.com/mailman/listinfo/cmake