Display extended version information from the build

[skliper]

The CFE build currently contains a 4-part version number, i.e. "6.4.1.0". This version number is is #define'd in a header file and is manually updated with each official release.

However, git and Cmake (see ticket #32) offer additional build information where the current git commitid and most recent tag name are built into a global object that is accessible at runtime. When it is available, this extended build information should be displayed along with the manually updated official version number.

The major benefit here is that it updates automatically with every commit, not just official releases. It also indicates the whether the source code tree has been modified from the pristine version in the commit ("dirty") or not. It is extremely useful to have this information built into the executable in order to verify the correct binary is loaded as well as being able to reproduce running binaries when needed.

[skliper]

Imported from trac issue 13. Created by jphickey on 2014-12-30T21:39:53, last modified: 2019-03-05T14:57:55

[skliper]

Trac comment by jphickey on 2015-01-05 10:52:44:

Git commit [changeset:ae3b0f84] on branch "trac-13-extended_version_info" addresses this.

[skliper]

Trac comment by jphickey on 2015-04-06 11:38:44:

This is ready for review/merge

[skliper]

Trac comment by sstrege on 2015-04-06 14:30:41:

This change creates multiple definitions for the CFE_ES_INITSTATS_INF_EID

[skliper]

Trac comment by jphickey on 2015-04-06 14:44:35:

Are you referring to the fact that the init code is now performing two CFE_EVS_SendEvent() calls using the same CFE_ES_INITSTATS_INF_EID?

If this will adversely affect code that is listening for these events, I could add a new EID for these.

The only real reason for making two calls is that it was too much information to try to stuff into a single call.

[skliper]

Trac comment by acudmore on 2015-04-07 08:54:37:

Do the changes depend on Cmake and Git?
Would something like CMAKE_BUILD be a more descriptive macro than ENHANCED_BUILD?

[skliper]

Trac comment by sstrege on 2015-04-07 12:28:56:

Yes, a new EID should be added. This supports the short event message that does not include the text string.

[skliper]

Trac comment by glimes on 2015-04-07 12:52:33:

Tested changeset [changeset:ae3b0f84] as part of the ic-2015-03-10 merge.

[skliper]

Trac comment by jphickey on 2015-04-09 14:53:25:

commit [changeset:545cc1d] has been added to address the concerns brought up in the CCB discussion on 4/7:

• Use different EIDs when publishing the version information.
• In order to reproduce an exact binary build when necessary, the scripts should allow the "build date" value to be overridden. The simplest way to accomplish this was via an environment variable. With the way this is implemented now, it will give preference to the variable "BUILDDATE" -- if set, the value will be used directly for this field. Otherwise, the current time will be used.

[skliper]

Trac comment by glimes on 2015-04-13 14:45:01:

Confirmed, tested as changeset [changeset:545cc1d]
which is applied as a direct child of the previous
merge [changeset:7d6f6d0].

[skliper]

Trac comment by glimes on 2015-04-13 14:46:00:

Part of integration candidate 2015-03-10,
committed to cFS CFE Development branch on 2015-04-10
as followup after merge [changeset:7d6f6d0].
Development branch advances to
this singleton changeset [changeset:545cc1d].

[skliper]

Trac comment by glimes on 2016-02-16 13:16:45:

Susie confirmed these tickets have been approved for CFE 6.5

[skliper]

Trac comment by jhageman on 2019-03-05 14:57:55:

Milestone renamed