I just learned how I can use
project(ProjectName VERSION 1.0)
and the configure_file to play with the version and embed it into the binary.
On project documentation I see it also accept a description string.
project(ProjectName VERSION 1.0 description_string)
So I want to use the current datetime at the time cmake is running
as the description string.
Wondering if I can use datetime, not commit datetime but current datetime at the time cmake is running?
You can use string(TIMESTAMP ...) like this:
string(TIMESTAMP RUN_TIME)
project(ProjectName VERSION 1.0 DESCRIPTION "${RUN_TIME}")
Note, however, that this will be populated only when CMake is actually run on this script. So, for example, you generated your project for, say, Visual Studio and work a few days on it there. If you didn't change the CMake file, remove CMake cache or run cmake on the script any other way your date will be stale.
Related
In my project I need to include different files for different build configurations and thus far I've been unable to find a way to do it via CMake.
My build command looks the following way:
cmake -DCMAKE_CONFIGURATION_TYPES=Debug2017;Debug2018;Debug2019;Release2017;Release2018;Release2019 -G"Visual Studio 14 2015" #and so on
In my CMakeLists.txt I want to have something that looks like:
if ($<$<CONFIG:Debug2017>: )
set (MAYA_DIRECTORY "C:/Program Files/Autodesk/Maya2017" )>
endif()
if ($<$<CONFIG:Debug2018>: )
set (MAYA_DIRECTORY "C:/Program Files/Autodesk/Maya2018" )>
endif()
#and so on; obviously script above don't work. I posted it just as an example of what I want to achieve
variable MAYA_DIRECTORY is used later on to set different other variables that are used for include_directories(…) and link_directories(…) calls.
If there is a way to do this by something other than generator expressions that would also work.
Thanks!
You don't. It is possible for single config generators to use CMAKE_BUILD_TYPE but that strategy fails for for multi-config generators like Visual Studio. This is mixing up what happens at configuration time and build time. The active configuration happens at build time.
Therefore you need a separate MAYA_DIRECTORY for each build config. Then you need to include each Maya into the build (I'm guessing they are external projects or something). Then you need to use a generator expressions to pick which Maya you want to use in the executable.
It would be something like this.
target_include_directories(myApp PRIVATE
$<$<CONFIG:Debug2016>:${MAYA_2016_INCS}>
$<$<CONFIG:Debug2017>:${MAYA_2017_INCS}> )
target_link_libraries(myApp PRIVATE
$<$<CONFIG:Debug2016>:${MAYA_2016_LIBS}>
$<$<CONFIG:Debug2017>:${MAYA_2017_LIBS} )
FYI, If you are creating multiple configuration types you need to seed them properly. That is make sure you create a *_Debug2017 with the debug flags and so on.
In CMake I'm doing something like this:
LINK_DIRECTORIES( $ENV{VARNAME}/lib )
However, that will expand the environment variable so that the generated visual studio project will have a hard coded path, e.g:
C:/PathToWhereVarNamePointed/lib
Is there a way to make the above call so that visual studio will end up the below instead?
$(VARNAME)/lib
Because CMake 2.8.1 changed how this value is interpreted (relative vs. absolute), in addition to escaping the dollar and the parens, you need to set the old policy:
CMAKE_POLICY( SET CMP0015 OLD )
LINK_DIRECTORIES(
\$\(VARNAME\)/lib
)
CMAKE_POLICY( SET CMP0015 NEW )
Then it shows up like:
The CMake docs say that LINK_DIRECTORIES is "rarely necessary". Are you sure this is the right way to do it?
I'm trying to raise the revision number with each build.
I've therefore tried to the project assembly information -> Assembly Version and File Version to
1 0 0 *
1 0 0 *
However, VS2017 tells me
"Assembly file version: In this field, wildcards ("*") aren't allowed.
How can I do this?
You should remove the AssemblyFileVersion attribute and just keep the AssemblyVersion. If AssemblyFileVersion is not present in the Assembly Information, the file version will automatically be set to the same as the AssemblyVersion at compile time.
Quoting the documentation:
If the AssemblyFileVersionAttribute is not supplied, the AssemblyVersionAttribute is used for the Win32 file versionthat is displayed on the Version tab of the Windows file properties dialog.
I found this:
https://marketplace.visualstudio.com/items?itemName=PrecisionInfinity.AutomaticVersions
It's hilarious that VS doesn't have this built-in.
I know this is a very old question, however it appears when googling "auto increment version visual studio".
Since the current answer doesn't really answer the question, this is what I did:
Assembly Version looks like 1 1 1 *
File Version like 1 1 1 0.
You cannot use wildcards (*) on the file version. If you use them on Assembly leave empty spaces after the wildcard (1 1 * EMPTY).
That works and the error
"Assembly file version: In this field, wildcards ("*") aren't
allowed."
does not appear.
If that still gives you trouble, you could remove the "deterministic" flag editing the .csproj
Yet another option is: https://neele.name/item/versioning-controlled-build
This one works with Visual Studio 2017.
I found it to be easy to use and has the advantage that you can choose to invoke it or not depending on if you are creating a test build or a release build.
Ensure the Projects "Deterministic" property is set to false by editing the .vbproj file:
<PropertyGroup>
<Deterministic>false</Deterministic>
</PropertyGroup>
Then open the AssemblyInfo.vb file and set the assembly version property like this: <Assembly: AssemblyVersion("1.0.*")>
Remove or comment-out the <Assembly: AssemblyFileVersion(...)> attribute since that cannot use wildcards, and if it isn't present, the file will inherit the version assembly number.
Setting the version number to 1.0.*, as in the above example, results in a version number similar to 1.0.8888.99999 where the build is equal to the number of days since January 1, 2000 local time, and the revision is equal to the number of seconds since midnight local time (without taking into account time zone adjustments for daylight saving time), divided by 2.
See the Docs site for details.
I have a project with documentation written in ReStructuredText. The docs are compiled to HTML when the project is built via cmake. It includes a line with a "last changed" date.
I wonder how hard it would be to set this date automatically, as, from time to time, I simply forget to update the last changed date when I edit the docs.
I thought about generating some additional file, like
date -d "#$(stat -c %Z Readme.rst)" +"%d.%m.%Y" > lastchange.txt
and to reference it in the source like
:Date: .. include:: lastchange.txt
But would it be possible to achieve such a reference with only RST? Or in a more elegant way? Because doint it like so, it would be necessary to create a "working copy" of the sources in the cmake build directory, because otherwise the reference won't be found. And if I do this, I can as well sed the date into the sources directly.
I have cross compiled a software for an HummingBoard-Pro (arm processor).
The software just receives some data using the lcm protocol.
If I use the cross compiled software, the data received by the application are invalid, while if I use on-board compiled software everything works fine.
-The software is exactly the same!
-I cross compiled using cmake and a specific arm toolchain.
Output example of cross compiled sw:
first value 5.73599e+107
second value 5.73599e+107
third value 5.73599e+107
Output example of on board compiled sw:
first value 1
second value 2
third value 3
Note: It's my first cross compilation attempt so probably something goes wrong but I haven't really idea about what.
CMakelists file
cmake_minimum_required(VERSION 3.1)
set(main_project_dir ${CMAKE_CURRENT_SOURCE_DIR})
set(external_dir ${main_project_dir}/external)
set(external_lcm_dir ${external_dir}/lcm_dir)
set(external_lcm ${external_lcm_dir}/lcm)
set(external_lcm_build ${external_lcm}/build)
set(external_lcm_gen_exe /usr/local/bin/lcm-gen)
set(lcm_input_file ${main_project_dir}/lcm_format_files/lcm_input_files/indrive.sensors.vanet.lcm)
set(lcm_libraries ${main_project_dir}/external/lcm_dir/lcm/build/lcm)
set(lmc_libraries_header ${main_project_dir}/external/lcm_dir/lcm/)
set(lcm_autogenerated_dir ${main_project_dir}/build/lcm_autogenerated_classes)
add_custom_target(
generate-lcm
COMMAND ${external_lcm_gen_exe} -x ${lcm_input_file} --cpp-hpath ${lcm_autogenerated_dir}
COMMENT "=================== Generating lcm files..."
)
add_subdirectory(testSender)
add_subdirectory(testReceiver)
TOOLCHAIN FILE
SET (CMAKE_SYSTEM_NAME Linux)
SET (CMAKE_SYSTEM_VERSION 1)
SET (CMAKE_SYSTEM_PROCESSOR arm)
INCLUDE_DIRECTORIES(/usr/hummingboard/usr/include /usr/hummingboard/include /usr/hummingboard/usr/include/arm-linux-gnueabihf/)
LINK_DIRECTORIES(/usr/hummingboard/usr/lib /usr/hummingboard/lib /usr/hummingboard/lib/arm-linux-gnueabihf )
SET(CMAKE_PREFIX_PATH /usr/arm-linux-gnueabihf/lib/
/usr/hummingboard/
/usr/hummingboard/lib/arm-linux-gnueabihf/
/usr/hummingboard/usr
/usr/hummingboard/usr/lib/arm-linux-gnueabihf/
)
SET (CMAKE_C_COMPILER /usr/bin/arm-linux-gnueabi-gcc)
SET (CMAKE_CXX_COMPILER /usr/bin/arm-linux-gnueabi-g++)
SET (CMAKE_FIND_ROOT_PATH /usr/hummingboard/ /usr/hummingboard/usr)
SET (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
SET (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Turning my comments into an answer
Your toolchain file looks like a mixture of two GNU toolchains, which is not allowed and could explain strange behavior of your software.
I would e.g. expect there to be a /usr/hummingboard/bin directory. And shouldn't there be a arm-linux-gnueabihf-gcc to match with /usr/arm-linux-gnueabihf/lib/.
My guess would be that you are mixing hard-float (hf) with soft-float libraries and native- with cross-compilers.
It gets visible with the value 5.73599e+107 = 0x7f800000 which means infinite.
To find the root-cause I would recommend to check your floating point settings. Please compare the compiler command lines between both builds (working vs. non-working) using verbose makefiles.
References
Assign infinity to float
Using CMake with GNU Make: How can I see the exact commands?