CMake policies issues was: Re: kdesupport/automoc

[Alexander Neundorf]

On Tuesday 22 June 2010, Alexander Neundorf wrote:
> 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_req
>uired 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.

Ok, I added cmake_policy(PUSH/POP) to Automoc4Config.cmake, so any policy 
changes done inside there don't propagate to the outside, so CMP0002 is not 
reset to NEW, so the duplicated target names should be ok.
Let me know if there are still problems.

Alex