[CMake] CMake 2.8.0 RC 1 ready for testing!

David Cole david.cole at kitware.com
Tue Sep 29 13:06:49 CEST 2009


On Tue, Sep 29, 2009 at 3:26 AM, Andreas Pakulat <apaku at gmx.de> wrote:

> On 28.09.09 16:08:22, Brad King wrote:
> > Andreas Pakulat wrote:
> > > On 25.09.09 16:07:21, Bill Hoffman wrote:
> > >> I am happy to announce that CMake 2.8.0 has entered the beta stage!
> You
> > >> can find the source and binaries here:
> http://www.cmake.org/files/v2.8/.
> > >>
> > >> I am sure I am leaving something out, but here is the list of changes
> > >> that I came up with.  (If you notice something missing please let me
> > >> know and I will add it to the official release when 2.8.0 is
> finalized.)
> > >> Changes in CMake 2.8.0 RC 1
> > >
> > > Here's another error (building kdevplatform):
> > >
> > > [ 57%] Built target kdevplatformvcs
> > > vcs/dvcs/tests/CMakeFiles/dvcsTest.dir/build.make:47:
> > > vcs/dvcs/tests/CMakeFiles/dvcsTest.dir/progress.make: No such file or
> > > directory
> > > make[2]: *** No rule to make target
> > > `vcs/dvcs/tests/CMakeFiles/dvcsTest.dir/progress.make'.  Stop.
> > > make[1]: *** [vcs/dvcs/tests/CMakeFiles/dvcsTest.dir/all] Error 2
> >
> > This is because you have two executable targets named 'dvcsTest'.
> > Even though they are in different directories, CMake has required
> > globally unique logical target names since 2.6:
> >
> >   http://www.cmake.org/cmake/help/cmake2.6docs.html#policy:CMP0002
> >
> > (Actually it always wanted them but didn't enforce it until 2.6).
> > Normally CMake 2.6 would have warned you about this problem, but
> > KDE requests OLD behavior:
> >
> >   FindKDE4Internal.cmake:# CMP0002: in KDE4 we have multiple targets with
> the same name for the unit tests
> >   FindKDE4Internal.cmake:cmake_policy(SET CMP0002 OLD)
> >
> > This line prevents the warning, which was nice at the time it was
> > written, but it also prevents KDE developers from seeing the hints
> > CMake normally provides to update their projects.
> >
> > CMake 2.8.0-rc1 has a bug that prevents the OLD behavior for this
> > policy from working correctly.  I'll fix it, but you should also
> > fix the project to avoid duplicate target names...we may not allow
> > them forever.
>
> Thanks for the info, I'll fix the project later. I believe however that I
> didn't see any warnings, which should now be posted if I understood
> correctly? Or is that part of the OLD behaviour still working?
>
>
If you set the policty to OLD, you should just get the OLD behavior and not
see any warnings...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090929/050e73af/attachment.htm 


More information about the Kde-buildsystem mailing list