[Cmake-commits] CMake branch, master, updated. v3.13.0-rc1-85-gaeb24db

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  aeb24db55400b16c9d53d10b50cdb4668ba93e5f (commit)
  from  e2dd6ac9776e4f5a1995dfc606480b627fdbce72 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aeb24db55400b16c9d53d10b50cdb4668ba93e5f
commit aeb24db55400b16c9d53d10b50cdb4668ba93e5f
Author: Kitware Robot 
AuthorDate: Fri Oct 12 00:01:08 2018 -0400
Commit: Kitware Robot 
CommitDate: Fri Oct 12 00:01:08 2018 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4d3e783..1bc2632 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 13)
-set(CMake_VERSION_PATCH 20181011)
+set(CMake_VERSION_PATCH 20181012)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Putting the git commit hash in a cmake variable

[Matt Schulte]

Ah, that's a good tip Elvis. The CONFIGURE_DEPENDS on the .git/index
would do the trick. I can set that up for now.

In the long run, its not that ideal because it forces a reconfigure on
every commit (which is annoying for developers at their desk).

My example above is actually a little more complex in real life. I
just simplified it for this e-mail. We only append the git hash to our
version string if we are on certain branches. So our version string
doesn't change on feature branches.

For now I think we'll bite the bullet and re-configure on every
commit. I'll keep mulling over the how to set this up. Thanks for the
idea!

-Matt
On Thu, Oct 11, 2018 at 12:26 PM Chuck Atkins  wrote:
>
>
>> COMMAND "${GIT_EXECUTABLE}" describe --always HEAD
>
>
> git describe is nice way to do it since you can get a monotonic-ish 
> increasing version number
>
>
>>
>> string(REGEX REPLACE "^.*-(.*)-g.*$" "\\1" MYAPP_VERSION_MICRO 
>> "${MYAPP_VERSION}")
>> ...
>> set(MYAPP_VERSION_MICRO "0")
>
>
> Only tangentially related, CMake commands and functions that deal with 
> version information refer to the 4th component as _TWEAK.
>
> - Chuck
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Building arguments to target_comple_definitions()

[Rob Boehne]

They were elided for brevity –

So in CMake parlance, what type is the last argument to 
target_compile_definitions?  Is it a list, string or something else?

From: Chuck Atkins 
Date: Thursday, October 11, 2018 at 2:55 PM
To: Rob Boehne 
Cc: CMake Mail List 
Subject: Re: [CMake] Building arguments to target_comple_definitions()

So, are you suggesting that I make a “dummy” target and fill it with the common 
options in compile_definitions() and include_directories() (et. al.)
Then make my OBJECT libraries (and the shared library) depend on the “dummy” 
target?

If that’s not the suggestion, I’m afraid I don’t see how I can use this to set 
the common flags

That's certainly one way you can solve the problem, i.e. making an interface 
library with the common defs, and a good idea at that, but that's not what I 
was referring to.  I was simply tying to explain that the error your getting 
trying to pass arguments to target_compile_options is because you're missing 
the visibility argument.

- Chuck
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Building arguments to target_comple_definitions()

[Chuck Atkins]

>
> So, are you suggesting that I make a “dummy” target and fill it with the
> common options in compile_definitions() and include_directories() (et. al.)
>
> Then make my OBJECT libraries (and the shared library) depend on the
> “dummy” target?
>

>
> If that’s not the suggestion, I’m afraid I don’t see how I can use this to
> set the common flags
>

That's certainly one way you can solve the problem, i.e. making an
interface library with the common defs, and a good idea at that, but that's
not what I was referring to.  I was simply tying to explain that the error
your getting trying to pass arguments to target_compile_options is because
you're missing the visibility argument.

- Chuck

>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Building arguments to target_comple_definitions()

[Rob Boehne]

So, are you suggesting that I make a “dummy” target and fill it with the common 
options in compile_definitions() and include_directories() (et. al.)
Then make my OBJECT libraries (and the shared library) depend on the “dummy” 
target?

If that’s not the suggestion, I’m afraid I don’t see how I can use this to set 
the common flags


From: Chuck Atkins 
Date: Thursday, October 11, 2018 at 2:12 PM
To: Rob Boehne 
Cc: CMake Mail List 
Subject: Re: [CMake] Building arguments to target_comple_definitions()

Hi Rob,

target_compile_definitions( CHUNK1 ${COMMON_DEFINITIONS}  CHUNK1_STUFF 
CHUNK_NAME=\”One\” )
target_compile_definitions( CHUNK2 ${COMMON_DEFINITIONS}  CHUNK2_STUFF 
CHUNK_NAME=\”Two\”)
target_compile_definitions( FooBar ${COMMON_DEFINITIONS}  )

This is what I was referring to.  Adding visibility to 
target_compile_definitions:

target_compile_definitions(CHUNK1 PRIVATE ${COMMON_DEFINITIONS} CHUNK1_STUFF 
CHUNK_NAME=\"One\")
target_compile_definitions(CHUNK2 PRIVATE ${COMMON_DEFINITIONS} CHUNK2_STUFF 
CHUNK_NAME=\"Two\")
target_compile_definitions(FooBar PRIVATE ${COMMON_DEFINITIONS})

All of the target_ commands take the format target_foo(target_name 
USAGE_VISIBILY bar1 bar2 bar3 ...).  target_link_libraries is the exception 
with everythign being PUBLIC by default but only because it pre-dates all the 
other target commands.

- Chuck
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Putting the git commit hash in a cmake variable

[Chuck Atkins]

> COMMAND "${GIT_EXECUTABLE}" describe --always HEAD
>

git describe is nice way to do it since you can get a monotonic-ish
increasing version number


>
> string(REGEX REPLACE "^.*-(.*)-g.*$" "\\1" MYAPP_VERSION_MICRO
> "${MYAPP_VERSION}")
> ...
> set(MYAPP_VERSION_MICRO "0")
>

Only tangentially related, CMake commands and functions that deal with
version information refer to the 4th component as _TWEAK.

- Chuck
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Building arguments to target_comple_definitions()

[Chuck Atkins]

Hi Rob,


> target_compile_definitions( CHUNK1 ${COMMON_DEFINITIONS}  CHUNK1_STUFF
> CHUNK_NAME=\”One\” )
>
> target_compile_definitions( CHUNK2 ${COMMON_DEFINITIONS}  CHUNK2_STUFF
> CHUNK_NAME=\”Two\”)
>
> target_compile_definitions( FooBar ${COMMON_DEFINITIONS}  )
>

This is what I was referring to.  Adding visibility to
target_compile_definitions:

target_compile_definitions(CHUNK1 PRIVATE ${COMMON_DEFINITIONS}
CHUNK1_STUFF CHUNK_NAME=\"One\")
target_compile_definitions(CHUNK2 PRIVATE ${COMMON_DEFINITIONS}
CHUNK2_STUFF CHUNK_NAME=\"Two\")
target_compile_definitions(FooBar PRIVATE ${COMMON_DEFINITIONS})

All of the target_ commands take the format target_foo(target_name
USAGE_VISIBILY bar1 bar2 bar3 ...).  target_link_libraries is the exception
with everythign being PUBLIC by default but only because it pre-dates all
the other target commands.

- Chuck
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Putting the git commit hash in a cmake variable

[Elvis Stansvik]

Den tors 11 okt. 2018 kl 18:28 skrev Matt Schulte :
>
> Thanks Isaiah and Michael.
>
> Both solutions work great if you just want to generate a header file
> that contains the git commit hash. I have seen these solutions before.
> I'd like to go a little farther and have the current commit hash
> available in a CMake variable. This means CMake must re-configure if
> the commit hash changes. That's what I have setup in my example above,
> but it only works with cmake 3.12 and ninja 1.8.2. I was curious if
> anyone else has tried to store the results of an command line tool in
> a variable and make sure its always up to date by forcing cmake to
> reconfigure if the output of the command no longer matches what is
> stored in that variable.

We have something like this in MyAppVersion.cmake:

find_package(Git QUIET REQUIRED)

execute_process(
COMMAND "${GIT_EXECUTABLE}" describe --always HEAD
WORKING_DIRECTORY "${CMAKE_SOURCE_DIR}"
RESULT_VARIABLE res
OUTPUT_VARIABLE MYAPP_VERSION
ERROR_QUIET
OUTPUT_STRIP_TRAILING_WHITESPACE)

set_property(GLOBAL APPEND
PROPERTY CMAKE_CONFIGURE_DEPENDS
"${CMAKE_SOURCE_DIR}/.git/index")

string(REGEX REPLACE "^([0-9]+)\\.([0-9]+)\\.([0-9]+).*$"
"\\1;\\2;\\3" _ver_parts "${MYAPP_VERSION}")
list(GET _ver_parts 0 MYAPP_VERSION_MAJOR)
list(GET _ver_parts 1 MYAPP_VERSION_MINOR)
list(GET _ver_parts 2 MYAPP_VERSION_PATCH)

if("${MYAPP_VERSION}" MATCHES "^.*-(.*)-g.*$")
string(REGEX REPLACE "^.*-(.*)-g.*$" "\\1" MYAPP_VERSION_MICRO
"${MYAPP_VERSION}")
else()
set(MYAPP_VERSION_MICRO "0")
endif()

and include it in our CMakeLists.txt.

That makes the output of `git describe` availabe in the MYAPP_VERSION
CMake variable.

The trick to make it always current is to append to
CMAKE_CONFIGURE_DEPENDS the .git/index file, so that the project is
re-configured if the Git index file is touched.

Can't remember where I found this trick, but it has worked fine for us
ever since.

Elvis

> On Thu, Oct 11, 2018 at 5:55 AM Michael Jackson
>  wrote:
> >
> > You could use a custom_target() instead, where that target is a simple 
> > shell/batch file that runs the needed git command and creates a simple 
> > header file. Then your main executable/library targets are dependent on 
> > that custom_target() so that it is run every time. We do something similar 
> > in our project. I added some "smarts" to it to at least compare the new 
> > output with the old output and only over write if they are different.
> >
> > --
> > Michael Jackson | Owner, President
> >   BlueQuartz Software
> > [e] mike.jack...@bluequartz.net
> > [w] www.bluequartz.net 
> >
> > On 10/10/18, 5:05 PM, "CMake on behalf of Matt Schulte" 
> >  wrote:
> >
> > Hi all,
> >
> > I'd like to set a CMake variable to the current git commit short hash.
> > This variable will be used as part of the version string for my
> > project (ex: "1.0.1+git.${SHORT_HASH}"). I can get at this short hash
> > by using execute_process and setting the resulting output to a
> > variable.
> >
> > ```cmake
> > execute_process(
> > COMMAND
> > git rev-parse --short HEAD
> > RESULT_VARIABLE
> > SHORT_HASH_RESULT
> > OUTPUT_VARIABLE
> > SHORT_HASH)
> > ```
> >
> > My issue is that cmake will only run execute_process once, during the
> > configure step. I need cmake to run this execute_process on every
> > build and, if the output has changed, reconfigure to make sure
> > SHORT_HASH is up to date.
> >
> > I came up with one solution to this issue: During the configure step,
> > I can write the current short hash to a file named short_hash.txt. On
> > every build, I'll re-compute the short hash and verify that the
> > computed short hash is the same as what is in short_hash.txt. If its
> > not, I'll write the new short hash to short_hash.txt. I then make
> > short_hash.txt an input to configure_file. This will cause cmake to
> > validate SHORT_HASH is properly set, and re-configure if its not.
> >
> > ```cmake
> > execute_process(
> > COMMAND
> > git rev-parse --short HEAD
> > RESULT_VARIABLE
> > SHORT_HASH_RESULT
> > OUTPUT_VARIABLE
> > SHORT_HASH)
> >
> > # If running in script mode (this runs on every build)
> > if (CMAKE_SCRIPT_MODE_FILE)
> > if (EXISTS "${SHORT_HASH_FILE}")
> > file(READ ${SHORT_HASH_FILE} READ_IN_SHORT_HASH)
> > else()
> > set(READ_IN_SHORT_HASH "")
> > endif()
> >
> > if (NOT ("${READ_IN_SHORT_HASH}" STREQUAL "${SHORT_HASH}"))
> > message(STATUS "Short hash is out of date")
> > # This will update short_hash.txt, causing cmake to reconfigure
> > file(WRITE ${SHORT_HASH_FILE} ${SHORT_HASH})
> > endif()
> >
> > # Else running as part of cmake configure
> > 

Re: [CMake] Putting the git commit hash in a cmake variable

[Matt Schulte]

Thanks Isaiah and Michael.

Both solutions work great if you just want to generate a header file
that contains the git commit hash. I have seen these solutions before.
I'd like to go a little farther and have the current commit hash
available in a CMake variable. This means CMake must re-configure if
the commit hash changes. That's what I have setup in my example above,
but it only works with cmake 3.12 and ninja 1.8.2. I was curious if
anyone else has tried to store the results of an command line tool in
a variable and make sure its always up to date by forcing cmake to
reconfigure if the output of the command no longer matches what is
stored in that variable.
On Thu, Oct 11, 2018 at 5:55 AM Michael Jackson
 wrote:
>
> You could use a custom_target() instead, where that target is a simple 
> shell/batch file that runs the needed git command and creates a simple header 
> file. Then your main executable/library targets are dependent on that 
> custom_target() so that it is run every time. We do something similar in our 
> project. I added some "smarts" to it to at least compare the new output with 
> the old output and only over write if they are different.
>
> --
> Michael Jackson | Owner, President
>   BlueQuartz Software
> [e] mike.jack...@bluequartz.net
> [w] www.bluequartz.net 
>
> On 10/10/18, 5:05 PM, "CMake on behalf of Matt Schulte" 
>  wrote:
>
> Hi all,
>
> I'd like to set a CMake variable to the current git commit short hash.
> This variable will be used as part of the version string for my
> project (ex: "1.0.1+git.${SHORT_HASH}"). I can get at this short hash
> by using execute_process and setting the resulting output to a
> variable.
>
> ```cmake
> execute_process(
> COMMAND
> git rev-parse --short HEAD
> RESULT_VARIABLE
> SHORT_HASH_RESULT
> OUTPUT_VARIABLE
> SHORT_HASH)
> ```
>
> My issue is that cmake will only run execute_process once, during the
> configure step. I need cmake to run this execute_process on every
> build and, if the output has changed, reconfigure to make sure
> SHORT_HASH is up to date.
>
> I came up with one solution to this issue: During the configure step,
> I can write the current short hash to a file named short_hash.txt. On
> every build, I'll re-compute the short hash and verify that the
> computed short hash is the same as what is in short_hash.txt. If its
> not, I'll write the new short hash to short_hash.txt. I then make
> short_hash.txt an input to configure_file. This will cause cmake to
> validate SHORT_HASH is properly set, and re-configure if its not.
>
> ```cmake
> execute_process(
> COMMAND
> git rev-parse --short HEAD
> RESULT_VARIABLE
> SHORT_HASH_RESULT
> OUTPUT_VARIABLE
> SHORT_HASH)
>
> # If running in script mode (this runs on every build)
> if (CMAKE_SCRIPT_MODE_FILE)
> if (EXISTS "${SHORT_HASH_FILE}")
> file(READ ${SHORT_HASH_FILE} READ_IN_SHORT_HASH)
> else()
> set(READ_IN_SHORT_HASH "")
> endif()
>
> if (NOT ("${READ_IN_SHORT_HASH}" STREQUAL "${SHORT_HASH}"))
> message(STATUS "Short hash is out of date")
> # This will update short_hash.txt, causing cmake to reconfigure
> file(WRITE ${SHORT_HASH_FILE} ${SHORT_HASH})
> endif()
>
> # Else running as part of cmake configure
> else()
> set(SHORT_HASH_FILE ${CMAKE_CURRENT_BINARY_DIR}/short_hash.txt)
> file(WRITE ${SHORT_HASH_FILE} ${SHORT_HASH})
>
> # The trick here is to make sure short_hash.txt is listed as a 
> byproduct
> add_custom_target(
> git_short_hash
> BYPRODUCTS
> ${SHORT_HASH_FILE}
> COMMAND
> ${CMAKE_COMMAND}
> "-DSHORT_HASH_FILE=${SHORT_HASH_FILE}"
> "-P" "${CMAKE_CURRENT_LIST_FILE}"
> COMMENT
> "Re-checking short hash..."
> VERBATIM
> USES_TERMINAL)
>
> # This configure_file makes cmake reconfigure dependent on 
> short_hash.txt
> configure_file(${SHORT_HASH_FILE} ${SHORT_HASH_FILE}.junk COPYONLY)
>
> message(STATUS "Short Hash: ${SHORT_HASH}")
> endif()
> ```
>
> This works great with cmake 3.12 and ninja 1.8.2! (I was really happy
> with how well it worked. I tip my hat to the cmake developers for
> this). However, it doesn't work with Makefiles, and causes ninja 1.7.2
> to get stuck in an infinite loop. On CMake 3.10 this will cause ninja
> 1.8.2 to generate a warning about a loop.
>
> Has anyone run into this issue before and have a better solution? Or
> is trying to execute a command before cmake checks if it should
> reconfigure a hack that should never be done?
>
> Thanks for the 

[CMake] Pre-install targets?

[David Thompson]

Hi all,

Is there a way to force a custom target (i.e., ADD_CUSTOM_TARGET) to be built 
just before installation?

We have documentation added as a custom target that is **not** passed the "ALL" 
keyword because generating the documentation is slow. However, that target 
creates files that have a matching INSTALL, so "make install" or "ninja 
install" will fail unless the target is built before installation. We want to 
encourage developers to configure with documentation turned on, but want 
buildbot/dashboard builds to work without magic options or special 
configuration.

Along those lines:

1. Is there any ordering of INSTALL(CODE ...) relative to INSTALL(FILES ...)? 
If it is guaranteed to run first, we could force the target to build that way.

2. Is there really nothing to replace the deprecated PRE_INSTALL_SCRIPT 
property?

Thanks,
David
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Putting the git commit hash in a cmake variable

[Michael Jackson]

You could use a custom_target() instead, where that target is a simple 
shell/batch file that runs the needed git command and creates a simple header 
file. Then your main executable/library targets are dependent on that 
custom_target() so that it is run every time. We do something similar in our 
project. I added some "smarts" to it to at least compare the new output with 
the old output and only over write if they are different. 

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net 

On 10/10/18, 5:05 PM, "CMake on behalf of Matt Schulte" 
 wrote:

Hi all,

I'd like to set a CMake variable to the current git commit short hash.
This variable will be used as part of the version string for my
project (ex: "1.0.1+git.${SHORT_HASH}"). I can get at this short hash
by using execute_process and setting the resulting output to a
variable.

```cmake
execute_process(
COMMAND
git rev-parse --short HEAD
RESULT_VARIABLE
SHORT_HASH_RESULT
OUTPUT_VARIABLE
SHORT_HASH)
```

My issue is that cmake will only run execute_process once, during the
configure step. I need cmake to run this execute_process on every
build and, if the output has changed, reconfigure to make sure
SHORT_HASH is up to date.

I came up with one solution to this issue: During the configure step,
I can write the current short hash to a file named short_hash.txt. On
every build, I'll re-compute the short hash and verify that the
computed short hash is the same as what is in short_hash.txt. If its
not, I'll write the new short hash to short_hash.txt. I then make
short_hash.txt an input to configure_file. This will cause cmake to
validate SHORT_HASH is properly set, and re-configure if its not.

```cmake
execute_process(
COMMAND
git rev-parse --short HEAD
RESULT_VARIABLE
SHORT_HASH_RESULT
OUTPUT_VARIABLE
SHORT_HASH)

# If running in script mode (this runs on every build)
if (CMAKE_SCRIPT_MODE_FILE)
if (EXISTS "${SHORT_HASH_FILE}")
file(READ ${SHORT_HASH_FILE} READ_IN_SHORT_HASH)
else()
set(READ_IN_SHORT_HASH "")
endif()

if (NOT ("${READ_IN_SHORT_HASH}" STREQUAL "${SHORT_HASH}"))
message(STATUS "Short hash is out of date")
# This will update short_hash.txt, causing cmake to reconfigure
file(WRITE ${SHORT_HASH_FILE} ${SHORT_HASH})
endif()

# Else running as part of cmake configure
else()
set(SHORT_HASH_FILE ${CMAKE_CURRENT_BINARY_DIR}/short_hash.txt)
file(WRITE ${SHORT_HASH_FILE} ${SHORT_HASH})

# The trick here is to make sure short_hash.txt is listed as a byproduct
add_custom_target(
git_short_hash
BYPRODUCTS
${SHORT_HASH_FILE}
COMMAND
${CMAKE_COMMAND}
"-DSHORT_HASH_FILE=${SHORT_HASH_FILE}"
"-P" "${CMAKE_CURRENT_LIST_FILE}"
COMMENT
"Re-checking short hash..."
VERBATIM
USES_TERMINAL)

# This configure_file makes cmake reconfigure dependent on 
short_hash.txt
configure_file(${SHORT_HASH_FILE} ${SHORT_HASH_FILE}.junk COPYONLY)

message(STATUS "Short Hash: ${SHORT_HASH}")
endif()
```

This works great with cmake 3.12 and ninja 1.8.2! (I was really happy
with how well it worked. I tip my hat to the cmake developers for
this). However, it doesn't work with Makefiles, and causes ninja 1.7.2
to get stuck in an infinite loop. On CMake 3.10 this will cause ninja
1.8.2 to generate a warning about a loop.

Has anyone run into this issue before and have a better solution? Or
is trying to execute a command before cmake checks if it should
reconfigure a hack that should never be done?

Thanks for the help!
Matt
-- 

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:
https://cmake.org/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 

[Cmake-commits] CMake branch, release, updated. v3.13.0-rc1-7-gbcfb245

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  bcfb2457030efcfdb84eef02230aa47f18072555 (commit)
   via  faf3d7d224ae2292e88b8238271a7ff97950ddf9 (commit)
   via  592064e026b1a3d6402496b5d37199e213569665 (commit)
   via  fb378fc4d756bf8424bca9c94c4d498b7c6974de (commit)
  from  a8a485715afe3017a514bc5fbd3a19a96d493aed (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Source/cmVisualStudio10TargetGenerator.cxx | 25 --
 Tests/Cuda/Complex/CMakeLists.txt  |  2 +-
 Tests/Cuda/ConsumeCompileFeatures/CMakeLists.txt   |  2 +-
 Tests/Cuda/MixedStandardLevels/CMakeLists.txt  |  2 +-
 Tests/Cuda/ObjectLibrary/CMakeLists.txt|  2 +-
 Tests/Cuda/WithC/CMakeLists.txt|  2 +-
 Tests/CudaOnly/CircularLinkLine/CMakeLists.txt |  2 +-
 Tests/CudaOnly/EnableStandard/CMakeLists.txt   |  2 +-
 Tests/CudaOnly/ExportPTX/CMakeLists.txt|  2 +-
 Tests/CudaOnly/GPUDebugFlag/CMakeLists.txt |  2 +-
 .../LinkSystemDeviceLibraries/CMakeLists.txt   |  2 +-
 Tests/CudaOnly/PDB/CMakeLists.txt  |  2 +-
 Tests/CudaOnly/ResolveDeviceSymbols/CMakeLists.txt |  2 +-
 Tests/CudaOnly/SeparateCompilation/CMakeLists.txt  |  2 +-
 Tests/CudaOnly/WithDefs/CMakeLists.txt |  2 +-
 15 files changed, 32 insertions(+), 21 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.13.0-rc1-84-ge2dd6ac

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  e2dd6ac9776e4f5a1995dfc606480b627fdbce72 (commit)
   via  9b20d6568a3cd8bfb71d28d67f2ec59f7f41f929 (commit)
   via  4f289cdc1ead3273ac248f41cd85ab8eccd4dec1 (commit)
   via  b7cba6ba00e9ae11d86fbb7fbf69eedff9e1c8c2 (commit)
   via  7d2ee4cb98b85946cc6b9befd33f20fab10e55bf (commit)
   via  bcfb2457030efcfdb84eef02230aa47f18072555 (commit)
   via  faf3d7d224ae2292e88b8238271a7ff97950ddf9 (commit)
   via  592064e026b1a3d6402496b5d37199e213569665 (commit)
   via  fb378fc4d756bf8424bca9c94c4d498b7c6974de (commit)
   via  0d988f98e531333b32d0f1628acf86f8baa22241 (commit)
   via  f9f96598df3164cf12b6da7764bc74361e3fa414 (commit)
   via  b56f2db87aebd34bfaf24439d56632aa3f3019f8 (commit)
   via  fc8955e8891c645cd369a3cc8b607a14a8ed5bd7 (commit)
   via  514f0b572ea8ca2ba87810aa8f48185f266a8eaa (commit)
   via  8f076acdb0af6e319005338e3e25d127043e3275 (commit)
  from  7a0f516ecdbc2ecc50123b54c223f917fc2864d3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e2dd6ac9776e4f5a1995dfc606480b627fdbce72
commit e2dd6ac9776e4f5a1995dfc606480b627fdbce72
Merge: 9b20d65 8f076ac
Author: Brad King 
AuthorDate: Thu Oct 11 11:43:57 2018 +
Commit: Kitware Robot 
CommitDate: Thu Oct 11 07:44:03 2018 -0400

Merge topic 'remove-AddCompileDefinitions'

8f076acdb0 cmLocalGenerator: Remove AddCompileDefinitions method

Acked-by: Kitware Robot 
Merge-request: !2470


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b20d6568a3cd8bfb71d28d67f2ec59f7f41f929
commit 9b20d6568a3cd8bfb71d28d67f2ec59f7f41f929
Merge: 4f289cd bcfb245
Author: Brad King 
AuthorDate: Thu Oct 11 07:42:35 2018 -0400
Commit: Brad King 
CommitDate: Thu Oct 11 07:42:35 2018 -0400

Merge branch 'release-3.13'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f289cdc1ead3273ac248f41cd85ab8eccd4dec1
commit 4f289cdc1ead3273ac248f41cd85ab8eccd4dec1
Merge: b7cba6b faf3d7d
Author: Brad King 
AuthorDate: Thu Oct 11 11:41:26 2018 +
Commit: Kitware Robot 
CommitDate: Thu Oct 11 07:41:42 2018 -0400

Merge topic 'vs-cuda-pdb'

faf3d7d224 VS: Add workaround for CUDA compiler PDB location with space
592064e026 VS: Drop workaround for CUDA compiler PDB location on CUDA 9.2+
fb378fc4d7 Tests: Fix Cuda test project names

Acked-by: Kitware Robot 
Merge-request: !2473


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b7cba6ba00e9ae11d86fbb7fbf69eedff9e1c8c2
commit b7cba6ba00e9ae11d86fbb7fbf69eedff9e1c8c2
Merge: 7d2ee4c 0d988f9
Author: Brad King 
AuthorDate: Thu Oct 11 11:41:00 2018 +
Commit: Kitware Robot 
CommitDate: Thu Oct 11 07:41:06 2018 -0400

Merge topic 'cmake_policy-get_warning'

0d988f98e5 cmake_policy: Add undocumented GET_WARNING command
f9f96598df Help: Convert FindOpenGL documentation to block comment

Acked-by: Kitware Robot 
Merge-request: !2472


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d2ee4cb98b85946cc6b9befd33f20fab10e55bf
commit 7d2ee4cb98b85946cc6b9befd33f20fab10e55bf
Merge: 7a0f516 b56f2db
Author: Brad King 
AuthorDate: Thu Oct 11 11:37:47 2018 +
Commit: Kitware Robot 
CommitDate: Thu Oct 11 07:37:59 2018 -0400

Merge topic 'install-subdirectory-order'

b56f2db87a Testing: Add test for CMP0082
fc8955e889 add_subdirectory: Run subdirectory install rules in correct order
514f0b572e Testing: Update hard-coded line numbers to [0-9]+ in some tests

Acked-by: Kitware Robot 
Merge-request: !2434


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d988f98e531333b32d0f1628acf86f8baa22241
commit 0d988f98e531333b32d0f1628acf86f8baa22241
Author: Kyle Edwards 
AuthorDate: Wed Oct 3 09:36:58 2018 -0400
Commit: Kyle Edwards 
CommitDate: Wed Oct 10 10:56:00 2018 -0400

cmake_policy: Add undocumented GET_WARNING command

This command is intended for modules that issue policy warnings so
they can get the warning string from CMake in a uniform manner,
rather than duplicating the string. Several modules been updated
to include an example of the usage of this new command.

diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index 31db25a..a7e80e7 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -230,11 +230,8 @@ if(DEFINED CMAKE_GENERATOR)
   if(_BundleUtilities_CMP0080 STREQUAL "NEW")
 message(FATAL_ERROR "BundleUtilities cannot be included at configure 
time!")
   elseif(NOT 

[Cmake-commits] CMake branch, master, updated. v3.13.0-rc1-69-g7a0f516

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  7a0f516ecdbc2ecc50123b54c223f917fc2864d3 (commit)
   via  2e1fe8fabed9485a5466305624f75c0318780d80 (commit)
   via  a6e0158712bd25256fb66cf21c047b81d65bc4fe (commit)
   via  f460bbd4c8afab56f93b9831f1f4d8336480fcc5 (commit)
   via  045b0beae13366420186337170d70e73ec96ebca (commit)
   via  0813581859bd61a9d30c97aa893030bea85f134e (commit)
  from  8563e29c81c23b758350ba1716ef3c6213b8c615 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a0f516ecdbc2ecc50123b54c223f917fc2864d3
commit 7a0f516ecdbc2ecc50123b54c223f917fc2864d3
Merge: 2e1fe8f 045b0be
Author: Brad King 
AuthorDate: Thu Oct 11 11:33:21 2018 +
Commit: Kitware Robot 
CommitDate: Thu Oct 11 07:33:39 2018 -0400

Merge topic 'FindwxWidgets-optional'

045b0beae1 FindwxWidgets: implement detailed components status on Windows
0813581859 FindwxWidgets: honor OPTIONAL_COMPONENTS

Acked-by: Kitware Robot 
Merge-request: !2447


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2e1fe8fabed9485a5466305624f75c0318780d80
commit 2e1fe8fabed9485a5466305624f75c0318780d80
Merge: 8563e29 a6e0158
Author: Brad King 
AuthorDate: Thu Oct 11 11:32:44 2018 +
Commit: Kitware Robot 
CommitDate: Thu Oct 11 07:32:54 2018 -0400

Merge topic 'ctest-done'

a6e0158712 ctest_submit: Add support for a "Done" part
f460bbd4c8 ctest_submit: Refactor file list to use a vector instead of a set

Acked-by: Kitware Robot 
Acked-by: Zack Galbreath 
Merge-request: !2405


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e0158712bd25256fb66cf21c047b81d65bc4fe
commit a6e0158712bd25256fb66cf21c047b81d65bc4fe
Author: Betsy McPhail 
AuthorDate: Thu Oct 4 11:34:27 2018 -0400
Commit: Brad King 
CommitDate: Wed Oct 10 06:55:59 2018 -0400

ctest_submit: Add support for a "Done" part

Teach CTest to submit Done.xml. Submission of this file indicates to
CDash that a build is complete and no more files will be uploaded. It
contains the build id returned by CDash and the current time.

This file is submitted last for a given build when using the
`ctest_submit()` command.

If submitting by PARTS, use `ctest_submit(PARTS Done)`.

diff --git a/Help/command/ctest_submit.rst b/Help/command/ctest_submit.rst
index 2ba6bef..426475c 100644
--- a/Help/command/ctest_submit.rst
+++ b/Help/command/ctest_submit.rst
@@ -33,6 +33,7 @@ The options are:
 ExtraFiles = Files listed by CTEST_EXTRA_SUBMIT_FILES
 Upload = Files prepared for upload by ctest_upload(), in Upload.xml
 Submit = nothing
+Done   = Build is complete, in Done.xml
 
 ``FILES ...``
   Specify an explicit list of specific files to be submitted.
diff --git a/Help/release/dev/ctest-done.rst b/Help/release/dev/ctest-done.rst
new file mode 100644
index 000..9ec0e24
--- /dev/null
+++ b/Help/release/dev/ctest-done.rst
@@ -0,0 +1,5 @@
+ctest-done
+--
+
+* The :command:`ctest_submit` command learned a new ``Done`` part that can be 
used
+  to inform CDash that a build is complete and that no more parts will be 
uploaded.
diff --git a/Source/CTest/cmCTestSubmitHandler.cxx 
b/Source/CTest/cmCTestSubmitHandler.cxx
index 38b5411..6ad0e03 100644
--- a/Source/CTest/cmCTestSubmitHandler.cxx
+++ b/Source/CTest/cmCTestSubmitHandler.cxx
@@ -56,6 +56,7 @@ public:
   std::string Filename;
   std::string MD5;
   std::string Message;
+  std::string BuildID;
 
 private:
   std::vector CurrentValue;
@@ -97,6 +98,8 @@ private:
   this->MD5 = this->GetCurrentValue();
 } else if (name == "message") {
   this->Message = this->GetCurrentValue();
+} else if (name == "buildId") {
+  this->BuildID = this->GetCurrentValue();
 }
   }
 };
@@ -645,6 +648,7 @@ void cmCTestSubmitHandler::ParseResponse(
  "   Submission failed: " << parser.Message << std::endl);
   return;
 }
+this->CTest->SetBuildID(parser.BuildID);
   }
   output = cmSystemTools::UpperCase(output);
   if (output.find("WARNING") != std::string::npos) {
@@ -1414,6 +1418,12 @@ int cmCTestSubmitHandler::ProcessHandler()
 files.erase(files.begin() + endPos, files.end());
   }
 
+  // Submit Done.xml last
+  if (this->SubmitPart[cmCTest::PartDone]) {
+this->CTest->GenerateDoneFile();
+files.push_back("Done.xml");
+  }
+
   if (ofs) {
 ofs << "Upload files:" << std::endl;
 int cnt = 0;
diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index 908eea1..d0d5db6 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx

[CMake] How am I supposed to use FindBLAS and FindLAPACK together?

[Alfredo Buttari]

Hello,
I cannot figure out how to use FindLAPACK after a succesful FindBLAS. The
problem is that I make a call to FindBLAS but then a subsequent call to
FindLAPACK ignores that a BLAS library was already found and searches for
BLAS once again; despite the fact that this second search is useless and
time consuming, the result of this second BLAS search may be different than
the first one. Is there a way to tell FindLAPACK not to search for BLAS
once again but, rather, to use the result of a previous call to FindBLAS ?

Besides, why does the FindLAPACK module use the BLA_VENDOR variable
internally and not something with a different name such as LAPACK_VENDOR,
for example?

Regards,
Alfredo
-- 

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:
https://cmake.org/mailman/listinfo/cmake