Re: [CMake] How to properly handle build version number in CMake script for project

[Robert Dailey]

OK weirdly, tested again, this also works and is a little more
simplified (although more confusing, since now we're intermixing
non-cache and cache variables with the same name; behavior is not
exactly clear, or well-defined.

if( BUILD_VERSION )
set( BUILD_VERSION ${BUILD_VERSION} )
unset( BUILD_VERSION CACHE )
else()
set( BUILD_VERSION 7.1.1.2 )
endif()

On Mon, Apr 10, 2017 at 1:32 PM, Robert Dailey  wrote:
> Actually this seems to work:
>
> if( BUILD_VERSION )
>
> set( version_override ${BUILD_VERSION} )
> unset( BUILD_VERSION CACHE )
> set( BUILD_VERSION ${version_override} )
> unset( version_override )
>
> else()
>
> set( BUILD_VERSION 7.1.1.2 )
>
> endif()
>
> It's a bit messy but gets the job done, and doesn't require
> configure_file(). Maybe there is a way to clean this up even more?
>
> I noticed that unset( BUILD_VERSION CACHE ) actually unsets non-cache
> versions of a variable too, so I had to use the temporary variable to
> transfer the value.
>
> On Mon, Apr 10, 2017 at 1:15 PM, Robert Dailey  
> wrote:
>> Sorry you're right, this isn't working because -D creates a cache
>> entry for the variable, which breaks it.
>>
>> So maybe more ideas on the configure_file() solution would be ideal...
>> unsetting the cache variable might work as well, I have to toy around
>> with this.
>>
>> On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens
>>  wrote:
>>> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey  
>>> wrote:
 Actually I think your idea does work. Why do you think it won't? I'm
 using it right now and so far it seems OK.
>>>
>>> I assumed (without testing, admittedly) is that it would fail if
>>> someone used -D to set the value,
>>> then changed some CMakeLists.txt file, then executed the build command
>>> again. I'd expect that
>>> to rerun cmake to update the build files and I'd fear that you'd then
>>> get BUILD_VERSION from
>>> the CMakeLists.txt file rather than the value explicitly set.
>>>
>>> However, I haven't tried it, and maybe it works fine (with the
>>> generators you care about) even without
>>> caching?
-- 

Powered by 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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Robert Dailey]

Actually this seems to work:

if( BUILD_VERSION )

set( version_override ${BUILD_VERSION} )
unset( BUILD_VERSION CACHE )
set( BUILD_VERSION ${version_override} )
unset( version_override )

else()

set( BUILD_VERSION 7.1.1.2 )

endif()

It's a bit messy but gets the job done, and doesn't require
configure_file(). Maybe there is a way to clean this up even more?

I noticed that unset( BUILD_VERSION CACHE ) actually unsets non-cache
versions of a variable too, so I had to use the temporary variable to
transfer the value.

On Mon, Apr 10, 2017 at 1:15 PM, Robert Dailey  wrote:
> Sorry you're right, this isn't working because -D creates a cache
> entry for the variable, which breaks it.
>
> So maybe more ideas on the configure_file() solution would be ideal...
> unsetting the cache variable might work as well, I have to toy around
> with this.
>
> On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens
>  wrote:
>> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey  
>> wrote:
>>> Actually I think your idea does work. Why do you think it won't? I'm
>>> using it right now and so far it seems OK.
>>
>> I assumed (without testing, admittedly) is that it would fail if
>> someone used -D to set the value,
>> then changed some CMakeLists.txt file, then executed the build command
>> again. I'd expect that
>> to rerun cmake to update the build files and I'd fear that you'd then
>> get BUILD_VERSION from
>> the CMakeLists.txt file rather than the value explicitly set.
>>
>> However, I haven't tried it, and maybe it works fine (with the
>> generators you care about) even without
>> caching?
-- 

Powered by 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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Robert Dailey]

Sorry you're right, this isn't working because -D creates a cache
entry for the variable, which breaks it.

So maybe more ideas on the configure_file() solution would be ideal...
unsetting the cache variable might work as well, I have to toy around
with this.

On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens
 wrote:
> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey  
> wrote:
>> Actually I think your idea does work. Why do you think it won't? I'm
>> using it right now and so far it seems OK.
>
> I assumed (without testing, admittedly) is that it would fail if
> someone used -D to set the value,
> then changed some CMakeLists.txt file, then executed the build command
> again. I'd expect that
> to rerun cmake to update the build files and I'd fear that you'd then
> get BUILD_VERSION from
> the CMakeLists.txt file rather than the value explicitly set.
>
> However, I haven't tried it, and maybe it works fine (with the
> generators you care about) even without
> caching?
-- 

Powered by 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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Bruce Stephens]

On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey  wrote:
> Actually I think your idea does work. Why do you think it won't? I'm
> using it right now and so far it seems OK.

I assumed (without testing, admittedly) is that it would fail if
someone used -D to set the value,
then changed some CMakeLists.txt file, then executed the build command
again. I'd expect that
to rerun cmake to update the build files and I'd fear that you'd then
get BUILD_VERSION from
the CMakeLists.txt file rather than the value explicitly set.

However, I haven't tried it, and maybe it works fine (with the
generators you care about) even without
caching?
-- 

Powered by 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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Hendrik Sattler]

Hi,

You could make it a non-cache variable and manage the caching yourself. The 
cache is your version.cmake. Before including it, check if the variable is set 
and update your version cmake file, possibly with configure_file().  After 
that, unset() the cache variable and include your cmake file, this having a 
non-cache variable. Add the cmake file to the list of dependent files to let 
cmake run when that file changes.

Regards

HS


Am 10. April 2017 15:29:20 MESZ schrieb Robert Dailey 
:
>I have a file called version.cmake that my root CMakeLists.txt
>includes. There is only a single line in this file:
>
>set( BUILD_VERSION 1.2.3.4 CACHE STRING "Version of the product" )
>
>I have two scenarios where this version number setting needs to work
>slightly differently from a CMake perspective:
>
>1. Our CI build server does a fresh clone of our repo, and generates
>from scratch. It sometimes needs to override the version number from
>the command line via arguments. So it will do:
>
>-D BUILD_VERSION=99.99.1.2
>
>This works since it's a cache variable. In fact, the current solution
>ONLY works well for this scenario (since it will allow overriding from
>command line, but also allow the file to set the value if it is not
>specified as a -D argument).
>
>2. Local work machine builds. Local builds never override using -D,
>they always use what is in the version.cmake file. However, because
>it's a cache variable and I'm not using FORCE with set(), it never
>updates if I change the version and push it to origin. This is the
>missing requirement: it needs to update when the number (value)
>changes in version control
>
>I thought of making a BUILD_VERSION_OVERRIDE that is only accepted on
>the command line, and if specified, it will set the BUILD_VERSION
>value to the overridden value. However, I don't like the idea of 2
>separate variables to manage this. Using a non-cache variable doesn't
>allow overriding with the same variable value on the command line
>either.
>
>What's the best solution here for my situation?

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

Powered by 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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Robert Dailey]

Actually I think your idea does work. Why do you think it won't? I'm
using it right now and so far it seems OK.

1. On build server, if it overrides it with -D, then it does not set
it by hand. If it doesn't override, it will use the fixed version in
the file
2. On work machines, it's never defined prior, so it sets it with the
fixed version.

On Mon, Apr 10, 2017 at 9:15 AM, Bruce Stephens
 wrote:
> On Mon, Apr 10, 2017 at 2:36 PM, Bruce Stephens
>  wrote:
>> You could do something like
>>
>> if(NOT "${BUILD_VERSION}")
>>   set(BUILD_VERSION 1.2.3.4)
>> endif()
>
>
> That doesn't work at all, come to think of it. I suspect your best bet
> is to handle
> the caching yourself (likely using a file in ${CMAKE_BINARY_DIR} and
> maybe "include(... OPTIONAL)"). That should allow whatever behaviour
> you want.
>
> I note that llvm's builds have the same sort of problem, so whatever
> fix is required
> isn't obvious even to obviously bright people. (That is, when the
> version switched
> from 4.0.0 to 5.0.0 my builds didn't change their version number. I
> had to remove the
> build directory and build again from clean.)
-- 

Powered by 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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Bruce Stephens]

On Mon, Apr 10, 2017 at 2:36 PM, Bruce Stephens
 wrote:
> You could do something like
>
> if(NOT "${BUILD_VERSION}")
>   set(BUILD_VERSION 1.2.3.4)
> endif()


That doesn't work at all, come to think of it. I suspect your best bet
is to handle
the caching yourself (likely using a file in ${CMAKE_BINARY_DIR} and
maybe "include(... OPTIONAL)"). That should allow whatever behaviour
you want.

I note that llvm's builds have the same sort of problem, so whatever
fix is required
isn't obvious even to obviously bright people. (That is, when the
version switched
from 4.0.0 to 5.0.0 my builds didn't change their version number. I
had to remove the
build directory and build again from clean.)
-- 

Powered by 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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to properly handle build version number in CMake script for project

[Bruce Stephens]

You could do something like

if(NOT "${BUILD_VERSION}")
  set(BUILD_VERSION 1.2.3.4)
endif()

On Mon, Apr 10, 2017 at 2:29 PM, Robert Dailey  wrote:
> I have a file called version.cmake that my root CMakeLists.txt
> includes. There is only a single line in this file:
>
> set( BUILD_VERSION 1.2.3.4 CACHE STRING "Version of the product" )
>
> I have two scenarios where this version number setting needs to work
> slightly differently from a CMake perspective:
>
> 1. Our CI build server does a fresh clone of our repo, and generates
> from scratch. It sometimes needs to override the version number from
> the command line via arguments. So it will do:
>
> -D BUILD_VERSION=99.99.1.2
>
> This works since it's a cache variable. In fact, the current solution
> ONLY works well for this scenario (since it will allow overriding from
> command line, but also allow the file to set the value if it is not
> specified as a -D argument).
>
> 2. Local work machine builds. Local builds never override using -D,
> they always use what is in the version.cmake file. However, because
> it's a cache variable and I'm not using FORCE with set(), it never
> updates if I change the version and push it to origin. This is the
> missing requirement: it needs to update when the number (value)
> changes in version control
>
> I thought of making a BUILD_VERSION_OVERRIDE that is only accepted on
> the command line, and if specified, it will set the BUILD_VERSION
> value to the overridden value. However, I don't like the idea of 2
> separate variables to manage this. Using a non-cache variable doesn't
> allow overriding with the same variable value on the command line
> either.
>
> What's the best solution here for my situation?
> --
>
> Powered by 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:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by 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:
http://public.kitware.com/mailman/listinfo/cmake