Mirror
/
ardupilot
mirror of https://github.com/ArduPilot/ardupilot
5
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ardupilot/APMrover2/version.h

13 lines
271 B
C
Raw Normal View History

APMrover2: use separate header for version macro Having the version macro in the config.h and consequently in the main vehicle header means that whenever the version changes we need to compiler the whole vehicle again. This would not be so bad if we weren't also appending the git hash in the version. In this case, whenever we commit to the repository we would need to recompile everything. Move to a separate header that is include only by its users. Then instead of compiling everything we will compile just a few files.
2016-05-05 19:10:08 -03:00
#pragma once
Global: use ap_version.h This header is used by waf to contain the generated version macros, particularly using the git hash. For waf it's better to be in a separate header since it then can keep track of changes on it a trigger recompilation. For the make build system, a dummy ap_version.h file has been added in the missing/ folder so both implementations can co-exist.
2016-05-05 19:18:36 -03:00
#include "ap_version.h"
Rover: Creating v3.0.1 beta release.
2016-05-31 21:45:51 -03:00
#define THISFIRMWARE "ArduRover v3.0.1beta1"
#define FIRMWARE_VERSION 3,0,1,FIRMWARE_VERSION_TYPE_BETA
APMrover2: use separate header for version macro Having the version macro in the config.h and consequently in the main vehicle header means that whenever the version changes we need to compiler the whole vehicle again. This would not be so bad if we weren't also appending the git hash in the version. In this case, whenever we commit to the repository we would need to recompile everything. Move to a separate header that is include only by its users. Then instead of compiling everything we will compile just a few files.
2016-05-05 19:10:08 -03:00
#ifndef GIT_VERSION
#define FIRMWARE_STRING THISFIRMWARE
#else
#define FIRMWARE_STRING THISFIRMWARE " (" GIT_VERSION ")"
#endif