Brad King wrote: > On 02/08/2013 04:56 PM, Brad King wrote: >> On 02/08/2013 03:16 PM, Stephen Kelly wrote: >>> My preference currently is to leave things as they are including the >>> long and useless string. >> >> Your analysis is quite extensive, thanks. > > I thought about this more over the weekend. I think we've made this much > harder than it needs to be. One of the main arguments for propagating > includes and defines through tll() is that all other usage requirements > like -fPIC will now be able to propagate through it too. However, why > don't those usage requirements turn into complex interface properties like > those we've been discussing for includes/defines? It's because they are > not applied until generation time.
Yes, but also because it's a boolean, not a list which must be uniq'd. > Ordering does not matter for compile definitions. Ordering does matter > for includes, but the reason we added <package>_NO_INTERFACES was due > to tll() changing the order for existing projects. I think it will be > much simpler to have usage requirements of all types simply appended > to the settings configured by the project: > > * Link libraries already work this way > > * Compile definitions order does not matter > > * Include directories order matters sometimes, but in cases the order > generated by appending usage requirements fails the project can > simply use tid() with $<TPROP:foo,INTERFACE_INCLUDE_DIRECTORIES> > themselves. Furthermore since the usage requirements always append > there is no compatibility issue for upstreams adding include dirs > so we may not need <package>_NO_INTERFACES. So GetIncludeDirectories() would be changed to generate the directories in this order: * The content of the INCLUDE_DIRECTORIES property * The INTERFACE_INCLUDE_DIRECTORIES of linked targets Correct? I think that would work, but implementation-wise, tll() will still populate some structures on the cmTarget for the includes anyway to keep track of backtraces. Those won't be exported though. The behavior may also be a little difficult to document because the result of the tll is always to append no matter the order of it relative to other calls: include_directories(/foo/bar) target_link_libraries(tgt other) include_directories(/bing/bat) That's really just a documentation concern. As there is no backward compatibility concern, I'm sure it's fine. > > This approach will drop all the complex generator expressions from > the interfaces altogether. Only the expressions written by the > user will ever be needed. For non-target library names passed to tll() > there is no issue because at generate time we will know they are not > targets. Yes, we won't even need to know at export-time, because the generator expressions will have been already evaluated. So, I think this is a good idea. I can work on it after minor-fixes is merged probably. The only commit in there that is not needed is the one changing LINKED. You can rebase that away or create another branch and cherry-pick the following two commits or whatever other git incantation you wish. They've all already been through the dashboard anyway. 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