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

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 comp

Re: [CMake] Building arguments to target_comple_definitions()

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

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

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

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

> 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 t

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

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

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 > a

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

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?

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 m

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

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] How am I supposed to use FindBLAS and FindLAPACK together?

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