[CMake] Expected behaviour of #cmakedefine

[Ian Cullen]

Agreed, version numbers will never not be set so #define is the better 
choice in this case. However this seems like an easy thing for users to 
trip-up on, particularly as only #cmakedefine is used in the 
configure_file() manual page.

Perhaps an additional example, or an INFO/WARNING section in the manual 
to highlight this 'issue'?


On 15/08/2018 13:56, J. Caleb Wherry wrote:
> I suppose it all depends on if there are situations where you don’t 
> want those variables set? To me, it doesn’t make sense to ever not 
> have version numbers set so I would use #define.
>
> -Caleb
>
> On Wed, Aug 15, 2018 at 8:32 AM Ian Cullen <ian.james.cullen at gmail.com 
> <mailto:ian.james.cullen at gmail.com>> wrote:
>
>     Hi,
>
>     I'm trying to create a header file containing version number
>     details but
>     am not sure if the following behaviour is expected or a bug.
>
>     Simplified example has 2 files
>
>     ==> CMakeLists.txt <==
>     cmake_minimum_required(VERSION 3.11)
>     project (
>        VersionTest
>        VERSION 1.0.4
>        )
>
>     configure_file (
>        "${PROJECT_SOURCE_DIR}/config.h.in <http://config.h.in>"
>        "${PROJECT_BINARY_DIR}/config.h"
>        @ONLY
>        )
>
>     ==> config.h.in <http://config.h.in> <==
>     #cmakedefine VersionTest_VERSION_MAJOR @VersionTest_VERSION_MAJOR@
>     #cmakedefine VersionTest_VERSION_MINOR @VersionTest_VERSION_MINOR@
>     #define VersionTest_VERSION_MINOR @VersionTest_VERSION_MINOR@
>
>
>     Running cmake creates the output file as required but it has the
>     following contents
>
>     ==> config.h <==
>     #define VersionTest_VERSION_MAJOR 1
>     /* #undef VersionTest_VERSION_MINOR */
>     #define VersionTest_VERSION_MINOR 0
>
>
>     Looking at the manual
>     (https://cmake.org/cmake/help/v3.12/command/configure_file.html),
>     this
>     appears to be because the number '0' is considered false by the if()
>     command, however '0' is valid within a version number, so perhaps
>     should
>     not be considered false in this context.
>
>     Is this a known issue? Is it recommended to use #define rather than
>     #cmakedefine for these types of files?
>
>     Thanks
>
>     -- 
>
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
>
>     Kitware offers various services to support the CMake community.
>     For more information on each offering, please visit:
>
>     CMake Support: http://cmake.org/cmake/help/support.html
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>
>     Follow this link to subscribe/unsubscribe:
>     https://cmake.org/mailman/listinfo/cmake
>
> -- 
> Sent from my iPhone 4s

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180817/a0e7dfc8/attachment.html>