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

2018-10-11 Thread Kitware Robot
t 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_VER

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

2018-10-11 Thread 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

Re: [CMake] Building arguments to target_comple_definitions()

2018-10-11 Thread 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

Re: [CMake] Building arguments to target_comple_definitions()

2018-10-11 Thread 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

Re: [CMake] Building arguments to target_comple_definitions()

2018-10-11 Thread 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

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

2018-10-11 Thread 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

Re: [CMake] Building arguments to target_comple_definitions()

2018-10-11 Thread 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

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

2018-10-11 Thread 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 >

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

2018-10-11 Thread 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

[CMake] Pre-install targets?

2018-10-11 Thread 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

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

2018-10-11 Thread 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

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

2018-10-11 Thread 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

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

2018-10-11 Thread 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

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

2018-10-11 Thread 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

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

2018-10-11 Thread 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