[CMake] Policy CMP0009 doesn't work (2.6.4)

[David Cole]

Ugh. This is a *horrible* bug. And it looks like it's my fault... Sometimes
it only takes 18 months or so for these things to come to light. :-(

To get it to work, put "FOLLOW_SYMLINKS" *before* the RELATIVE keyword. The
implementation has a bug that treats FOLLOW_SYMLINKS as one of the globbing
expressions if it occurs after RELATIVE. Doesn't help that the documentation
for the file command encourages you to put FOLLOW_SYMLINKS after RELATIVE...

The other bug is a missing "break" when the policy value is set to OLD. You
are correct: it should not warn you if you explicitly set it to OLD.

Could you file a bug for this issue in the bug tracker and attach a small
.tar.gz of an example project that demonstrates the problem? Reply with the
bug number if you're able to do that: I'll make sure to assign it to myself.

Thanks, (and sorry for the hassle),
David Cole


On Wed, Mar 17, 2010 at 9:17 PM, Chris Hillery <chillery-cmake at lambda.nu>wrote:

> I couldn't find any way to search the CMake bug tracker, so it's entirely
> possible this is already filed. I didn't see any reference to it in my
> mailing list archives, however.
>
> Policy CMP0009 is documented (when set to NEW) to make FILE(GLOB_RECURSE)
> only follow symlinks if the FOLLOW_SYMLINKS flag is set.
>
> However, in practice, I find that when CMP0009 is set to NEW, symlinks are
> not followed *even if* FOLLOW_SYMLINKS is specified.
>
> IF(COMMAND cmake_policy)
>   CMAKE_POLICY(SET CMP0009 NEW)
> ENDIF(COMMAND cmake_policy)
>
> FILE(GLOB_RECURSE TESTFILES RELATIVE "${CMAKE_CURRENT_SOURCE_DIR}"
> FOLLOW_SYMLINKS "*.xq")
>
> In this case, the current source directory contains a symlink to a
> subdirectory containing *.xq files, and TESTFILES willl not contain those
> paths.
>
> If however I set the policy CMP0009 to OLD, I'll get all those files, the
> same as if I do not set the policy to anything, *In either case*, I get a
> warning message about setting it, but the symlinks will be followed. (This
> is another bug - explicitly setting the policy to OLD should disable the
> warning, shouldn't it?)
>
> As mentioned in the subject, this is with CMake 2.6-patch 4. I'm afraid I
> have not yet been able to test this out with CMake 2.8. I don't know if
> Kitware does maintenance releases for previous revisions.
>
> Ceej
> aka Chris Hillery
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100318/ebc5b771/attachment.htm>