Brad King wrote: > On 01/28/2013 12:27 PM, Stephen Kelly wrote: >>>> Yes. However code like this would be ambiguous until generate-time: >>>> >>>> target_include_directories(foo PRIVATE bar) >>>> >>>> Is bar a target or a directory? That means storing a longer string for >>>> bar: >>> >>> Simply saying that an existing directory with the given name has >>> priority over a target with the same name would not be ok ? >> >> Currently we do the opposite. First check if 'bar' is a target name, and >> if not, then treat it as a directory. > > Can we consider using syntax to make this unambiguous? > > For non-targets we can require at least one slash to subsume full paths > and allow relative paths: > > target_include_directories(foo PRIVATE bar/ ./zot)
That wouldn't work. I needed this patch: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aca4916b2c124c6ec198c1f88329379458c93727 for this error: http://open.cdash.org/testDetails.php?test=173056412&build=2758124 > Perhaps the existence of a non-slash subdirectory could also be enough > for a non-target. > >> There is the disadvantage that the case of >> target_compile_definitions(foo PRIVATE SOME_DEFINE) >> now expands in the COMPILE_DEFINITIONS property to >> "$<$<TARGET_DEFINED:SOME_DEFINE>: $<TARGET_PROPERTY:SOME_DEFINE,INTERFACE_COMPILE_DEFINITIONS>;$<$<NOT: $<TARGET_DEFINED:SOME_DEFINE>>:SOME_DEFINE>" > > If SOME_DEFINE is *already* a target then this is not needed. > Only out-of-order cases need it. Yes, but that is the common case. > Also we should be able to perform > partial evaluation at generate time so that the exported interface > does not have this. Users could also write > > target_compile_definitions(foo PRIVATE bar=) > > to state that 'bar' is a definition name and not a target. Yes. > We could > also allow/accept a "-D" in front of definition names and have tcd() > strip them out when setting the property. I don't like that idea. It already makes add_definitions complex. > This would also help in > cases where variables contain lists meant for the old add_definitions > command which wants -D. True, but I think moving away from having a compiler-specific syntax to add definitions is a good thing. > What's missing is a concise syntax to say that a string *is* a target. > One could write > > $<TARGET_PROPERTY:bar,INTERFACE_COMPILE_DEFINITIONS> > > but that exposes the plumbing. Ideas? 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
