On Sunday 27 January 2013, Stephen Kelly wrote: > Alexander Neundorf wrote: > >> > Is there a reason why > >> > target_include_directories() should behave differently ? > >> > >> That results from the semantics of the INCLUDE_DIRECTORIES property and > >> http://public.kitware.com/Bug/view.php?id=13188 > > > > Ok. > > This applies to setting the target property directly. > > But, I think target_include_directories() could still handle relative > > paths so that CMAKE_CURRENT_SOURCE_DIR is prepended before it is set as a > > target property. > > 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 ? This would mean that directories "shadow" targets (or only not-yet-existing targets), while the other way round targets shadow directories. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5734/focu > s=5920 > > https://gitorious.org/~steveire/cmake/steveires- > cmake/commit/6fcdd6e4d47d0469baad228a84ebb9269dceb488 > > I don't know if that has a big impact but it's an unfortunately long string > to have to store for such a small input. > > We can also allow relative directories in a later release anyway. I'd > prefer at this point to be focussed on things which do have to be in this > release. Yes. Alex -- 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
