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
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
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
>
> 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
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
> 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
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
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
>
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
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
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
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
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
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
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
15 matches
Mail list logo