Brad King wrote: >> It seems that the meaning of INTERFACE libraries is being overloaded >> with the opposite of their meaning. > > The meaning of INTERFACE is that it specifies usage requirements > without itself building anything.
In this, it is the same as IMPORTED libraries. A key distinction is that INTERFACE libraries might have a place in the generated buildsystem, for example to show relevant include directories in an IDE. > Specifying a library name to > be placed on the link line is a usage requirement. IMPORTED_LIBNAME doesn't look like, walk like or quack like a duck, erm, I mean usage requirement. It is designed to not have a porcelain command, a corresponding INTERFACE_ property, allow appending, allow generator expressions, be determined by the link interface, result in transitive accumulation at the end for consumers. By current 'design language' it is not a 'usage requirement', just like IMPORTED_LOCATION, LOCATION, $<TARGET_FILE> and others are not 'usage requirements'. > The target > does not build the named library. I've updated the documentation > to use better wording for this: > > An interface library builds no library file itself but does specify > usage requirements for its consumers. The ``IMPORTED_LIBNAME`` > property may be set to specify a single library name to be placed > on the link line in place of the interface library target name as > a requirement for using the interface. I quoted the documentation to show that requiring the IMPORTED_LIBNAME to be on INTERFACE libraries is the wrong approach. I still think the topic overloads INTERFACE libraries with their semantic opposite. http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries "An INTERFACE target has no LOCATION and is mutable" ... "or it has a reference to a location relevant only on the filesystem which is not mutable"! The IMPORTED_LIBNAME is a departure from a lot of things in that doc section because it overloads INTERFACE libraries with their opposite. >> How about allowing the IMPORTED_LIBNAME for only 'UNKNOWN IMPORTED' >> libraries instead. > > We already allow $<TARGET_FILE:...> for UNKNOWN IMPORTED libraries > so they need an IMPORTED_LOCATION with a full path like any other. Is it impossible to implement $<TARGET_FILE:...> for UNKNOWN IMPORTED libraries such that it reports an error if IMPORTED_LIBNAME is set? I don't know why it would be impossible. Another option is add_library(Foo BIKESHED IMPORTED) but I don't think that's really necessary, unless it is impossible to implement $<TARGET_FILE:...> for UNKNOWN IMPORTED libraries such that it reports an error if IMPORTED_LIBNAME is set. The reason for this IMPORTED_LIBNAME feature is that the opengl32 is "unknown", or at least the full path to it is. >> Also the changes regarding MAP_IMPORTED_CONFIG for INTERFACE libraries >> can be implemented separately if they make sense (I don't know what's >> motivating them) instead having them as a side effect of the branch as it >> is currently. > > They are needed to select the proper IMPORTED_LIBNAME_<CONFIG> > possibly mapped from the consuming project's configuration. > The fact that this could be done with just the hunk > > - std::string const locPropBase = "IMPORTED_LOCATION"; > + std::string const locPropBase = > + this->GetType() == INTERFACE_LIBRARY? > + "IMPORTED_LIBNAME" : "IMPORTED_LOCATION"; > > shows how purely IMPORTED_LIBNAME corresponds to IMPORTED_LOCATION. I don't think the simplicity of a small hunk is a good deciding factor. Implementing the feature for UNKNOWN_LIBRARY would be almost as simple, and within the bounds of reasonably simple as far as I can tell. Maybe I'm missing something that makes that hard or impossible. Anyway, my remark wasn't about correspondance of IMPORTED_LIBNAME and IMPORTED_LOCATION, but correspondance of MAP_IMPORTED_CONFIG and INTERFACE libraries. I still don't understand why correspondance of MAP_IMPORTED_CONFIG and INTERFACE libraries is important, independent of this feature. MAP_IMPORTED_CONFIG appears to be relevant to IMPORTED_LIBNAME, but I as don't see what couples that to INTERFACE libraries, I find it hard to reason about that part/intention of the patch. Also, if IMPORTED_LIBNAME and IMPORTED_LOCATION correspond so closely, why don't INTERFACE libraries support both? For me the reason is that IMPORTED_LIBNAME and IMPORTED_LOCATION correspond, but IMPORTED_LIBNAME and INTERFACE libraries do not. Thanks, Steve. -- 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-developers
