I've force pushed to my clone again. I haven't added tests yet, and I've only been smoke testing as I go along.
Brad King wrote: > In the tll() signature policy I think LINK_PUBLIC/LINK_PRIVATE should > be an alias for PUBLIC/PRIVATE. The "old" signatures are only the > one without any keywords plus the one with LINK_INTERFACE_LIBRARIES. > The "new" signatures are the (LINK_)?(PUBLIC|PRIVATE|INTERFACE) mode. > That is why we need a policy to make the old and new sigs exclusive. Currently in my patch, the LINK_PUBLIC and LINK_PRIVATE are considered old signatures. That's easy to document and keeps most relevant existing documentation together without changing it. As a consequence of being part of the old signature, the use of LINK_PRIVATE determines whether the old LINK_INTERFACE_LIBRARIES is populated with an empty value. The use of the new signature with PRIVATE determines whether to populate the new INTERFACE_LINK_LIBRARIES property. It might be possible to control whether the INTERFACE_LINK_LIBRARIES is populated with an empty value determined by the policy alone (and make LINK_PRIVATE an alias for PRIVATE as you suggest), but for anyone transitioning (and using EXPORT_LINK_INTERFACE_LIBRARIES) it is more things to think about, it is more nuances to document in the policy and in the tll() documentation and it is more complex to implement. Similarly, for static libraries, we want to populate the INTERFACE_LINK_LIBRARIES with different stuff (genexes) when using the new signature. Again, that could be controlled by the policy alone, but for the same complexity , documentation and nuance arguments above, I don't think it should be. I think a clean break is a better idea. > Instead we should wrap the "private" link-only dependencies in an > expression because they are the ones that do not belong in the > interface. Perhaps use $<LINK_PRIVATE:...> or $<LINK_ONLY:...> > where ... can even be a list to avoid verbosity for adjacent > link-only entries. I've implemented LINK_ONLY now. The implementation of the genex supports lists, but the implementation of target_link_libraries would need to be refactored to emit groups instead of single libraries in order to take advantage of it. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
