[CMake] CMake 2.8.0 RC 1 ready for testing!

Andreas Pakulat apaku at gmx.de
Tue Sep 29 07:31:06 EDT 2009


On 29.09.09 09:26:30, Andreas Pakulat 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?

Renaming the target did fix the build problems

Andreas

-- 
Be different: conform.


More information about the CMake mailing list