Brad King wrote: > And another. Here is new documentation I've written based on this > discussion.
Done now. I would really prefer if you would commit this directly to the branch instead, as you had written it locally already. There is no point in having to go through me. The branch can be our collaboration point. Me copying your patch and pushing it myself feels like needless busy-work. Simliarly with the link-type keywords in the INTERFACE_LINK_LIBRARIES property check, you might not like the message string that I used in the error, you might ask me to change it, etc and we'll end up doing more trips through me, more latency. Please feel free to update it directly if that is the case. I'm not sure about DEBUG_CONFIG either. I think I'd prefer a more generic solution like $<COMPATIBLE_CONFIG:cfg> which would account for MAP_IMPORTED_CONFIG_<CONFIG> too. It's something worth discussing at least, and the discussion could go on past next Tuesday. If we do discuss it and insist that it's a solved-problem before add- INTERFACE_LINK_LIBRARIES-property can be merged, that would mean that the entire add-INTERFACE_LINK_LIBRARIES-property topic would not get merged to master for another week. I have at least 7 topics depending on that one being in master. I don't think the $<CONFIG:Debug> is so important that it should block that. It's a minor limitation which could equally be addressed after add-INTERFACE_LINK_LIBRARIES-property is in, in parallel with all the other stuff which depends on that. How can we best prevent scope-creep in topics? A few weeks ago I didn't have all the export-related stuff for INTERFACE_LINK_LIBRARIES in the same commit that introduced it, but I had follow-up commits in a follow-up topic to handle export() and install(EXPORT) for it. That would have simplified the commit that actually added INTERFACE_LINK_LIBRARIES I think, and I would still have been able to add most of my follow-up topics once it was in. You would have probably noticed that it was missing (exactly as you did with the context-target stuff and the static library conversion of link implementation into link interface in exports), and it might be harder for you to keep track of and review. Do you have any preference? If I have patches or features which other pending topics depend on, should I try to get a partial-implementation of limited scope in first and point to the other topics in gitorious, or does that not work for you? As a side-note, I'm no longer aiming to get the INTERFACE_LIBRARY type into 2.8.11 due to time constraints and incomplete implementation. It will have to wait until 2.8.12. > Please update the topic to implement the tll() behavior > with respect to the policy and LINK_PUBLIC. I pushed that to no-export-old-link-interface branch in my gitorious clone a few days ago. I guess I should have pointed it out, but I didn't realize it was a blocker for add-INTERFACE_LINK_LIBRARIES-property to get in. It also might open up new questions about documentation and implementation, and might introduce new failures in the dashboard. I'd prefer to discuss and merge it separately after add-INTERFACE_LINK_LIBRARIES-property is in. Otherwise add-INTERFACE_LINK_LIBRARIES-property will never get in. If you disagree, please cherry-pick it to the add-INTERFACE_LINK_LIBRARIES- property branch and merge it to next yourself so that we can move forward with other things. 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
