CMake policies issues was: Re: kdesupport/automoc

[Alexander Neundorf]

On Monday 21 June 2010, Jussi Kekkonen wrote:
> On 21 June 2010 22:49, Alexander Neundorf <neundorf at kde.org> wrote:
> > On Monday 21 June 2010, Jussi Kekkonen wrote:
> >> SVN commit 1140880 by jkekkonen:
> >>
> >> Reverting r1140777 as causing some nasty cmake funkyness, discussed in
> >> #kde-devel
> >
> > I don't consider "some nasty cmake funkyness" an explanation what issues
> > this line caused.
> > Please explain, because without this line the cmake files for automoc can
> > be considered broken.
> > If you have questions about the buildsystem, please ask on
> > kde-buildsystem at kde.org or on k-c-d.
> >
> > Alex
> >
> >>  M  +0 -2      Automoc4Config.cmake
> >>
> >>
> >> --- trunk/kdesupport/automoc/Automoc4Config.cmake #1140879:1140880
> >> @@ -1,6 +1,4 @@
> >>
> >> -cmake_minimum_required( VERSION 2.6.4 FATAL_ERROR )
> >> -
> >>  # It also adds the following macros
> >>  #  AUTOMOC4(<target> <SRCS_VAR>)
> >>  #    Use this to run automoc4 on all files contained in the list
> >> <SRCS_VAR>.
>
> Hi, I committed that revert because of this line in #kde-devel
> 1940.18 < marc_kdab_> pinotree: just revert that commit to
> Automoc4Config.cmake - I don't know enough cmake to know where the
> version check needs to go, and the cmake docs don't say
>
> Some errors what came from that commit, examples are from kdelibs:
> this first one comes similarly in multiple times
>
> CMake Error at cmake/modules/KDE4Macros.cmake:854 (add_custom_target):
>   add_custom_target cannot create target "buildtests" because another
> target with the same name already exists.  The existing target is a custom
> target created in source directory
> "/home/kde4/src/KDE/kdelibs/nepomuk/test".  See documentation for policy
> CMP0002 for more details.
> Call Stack (most recent call first):
>   kdecore/tests/CMakeLists.txt:6 (kde4_add_unit_test)
>   kdecore/tests/CMakeLists.txt:20 (KDECORE_UNIT_TESTS)
>
> the final one:
>
> CMake Error in CMakeLists.txt:
>  No cmake_minimum_required command is present.  A line of code such as
>
>    cmake_minimum_required(VERSION 2.8)
>
>  should be added at the top of the file.  The version specified may be
> lower if you wish to support older CMake versions for this project.  For
> more information run "cmake --help-policy CMP0000".
>
> I CC:d marc too, in hope this is enough information to someone knowing
> how it should be done to make it all work.

Hmm, this is related to CMake policy CMP0011:
http://www.cmake.org/cmake/help/cmake2.6docs.html#policy:CMP0011

In FindKDE4Internal.cmake CMP0002 is set to OLD, so we can have multiple 
targets with the same name:
http://www.cmake.org/cmake/help/cmake2.6docs.html#policy:CMP0002
(which we use as can be seen above e.g. for the "buildtests" target.

By having the cmake_minimum_required() in Automoc4Config.cmake these policies 
are reset to their default values as they are in 2.6.4:
http://www.cmake.org/cmake/help/cmake2.6docs.html#command:cmake_minimum_required
http://www.cmake.org/cmake/help/cmake2.6docs.html#command:cmake_policy


So, if I don't set CMP0011 to OLD in FindKDE4Internal.cmake, many things will 
go wrong because *every* project will *have* to put a consistent 
cmake_minimum_required(VERSION 2.6.4)
...
cmake_policy(...)

as it is done now in FindKDE4Internal.cmake into their toplevel 
CMakeLists.txt.

With CMP0011, I can adjust the policies so we are backwards compatible, but 
these settings can be changed by any other included/find_packaged() modules.

I guess the best thing to do for now is to add something with 
cmake_policy(PUSH/POP) and proper cmake version checking to 
Automoc4Config.cmake.
Or not to need to use the REALPATH argument for get_filename_component().
We'll figure it out.

Alex