[CMake] [cmake-developers] CMake 2.8.12-rc1 Released

[Alexander Neundorf]

On Thursday 22 August 2013, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Tuesday 20 August 2013, Robert Maynard wrote:
> >>  Introduced CMake Policy 21:
> >>   It is now an error to use relative paths to include_directories.
> > 
> > Why is this necessary ?
> > The documentation for this policy says:
> > "The base path for such relative entries is not well defined."
> > 
> > I don't understand this.
> > Why isn't it simply interpreted as relative to
> > ${CMAKE_CURRENT_SOURCE_DIR} in the CMakeLists.txt where the property is
> > set ?
> > include_directories(), link_directories() and I think more or less all
> > other commands interpret relative paths as relative to
> > ${CMAKE_CURRENT_SOURCE_DIR}.
> 
> I think the bug is in the release notes entry.
> 
> This relates to commit eabefa8b02b399b00aea83185b6b364ab5b6aa3d.
> 
> Relative paths can still be used with the include_directories() command.
> This relates mostly to using set_property and using generator expressions
> where the base path is not well-defined until generate-time.


Yes, I understood this.

-----------------------
cmake_minimum_required(VERSION 2.8.12)

include_directories( myHeaders/ )

add_executable(blub blub.c)

add_executable(foo foo.c)
set_target_properties(foo PROPERTIES INCLUDE_DIRECTORIES myHeaders/foo/ )

add_executable(bar bar.c)
set_target_properties(bar PROPERTIES INCLUDE_DIRECTORIES myHeaders/bar/ )

-----------------------

Purely from a user POV, why should the code above result an error ?

Everything there uses relative paths: the filenames, the include dirs.
IMO it's quite obvious that the INCLUDE_DIRECTORIES target property should be 
interpreted as relative to the current directory.
It could be argued whether in the case that the target property is set in a 
different directory than where the target has been created, the source dir of 
the target should be used or ${CMAKE_CURRENT_SOURCE_DIR} should be used.
With 2.8.11, if I see correctly, the source dir of the target is used, and IMO 
if this is documented this is perfectly fine IMO.
In the common case it will just work, and in the other cases the developer 
probably knows that he is doing something special and can be expected to make 
it a full path then.


Beside that, I played around with it a bit.
If 2.8.12 is required, it errors out, as documented.

If I use 2.8.12 and require 2.8.11:

-----------------------
cmake_minimum_required(VERSION 2.8.11)

add_executable(foo foo.c)
set_target_properties(foo PROPERTIES
           INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/myHeaders/foo/ )

add_executable(bar bar.c)
set_target_properties(bar PROPERTIES INCLUDE_DIRECTORIES myHeaders/bar/ )
-----------------------

Then for "foo" the full path is used as include dir, for "bar" the relative 
path is not used at all as include dir:
[ 50%] Building C object CMakeFiles/bar.dir/bar.c.o
/usr/bin/cc    -o CMakeFiles/bar.dir/bar.c.o   -c 
/home/alex/src/CMake/tests/relincdir/bar.c 

Is this expected ?


If I use 2.8.11 and require 2.8.11, then the relative path is used as include 
dir for "bar":
[ 50%] Building C object CMakeFiles/bar.dir/bar.c.o
/usr/bin/cc   -ImyHeaders/bar    -o CMakeFiles/bar.dir/bar.c.o   -c 
/home/alex/src/CMake/tests/relincdir/bar.c


So this seems to behave differently than in 2.8.11 even if 2.8.11 is required 
(and so the policy should be set accordingly).

Alex