Set CMake project version based on config.inc

[hannes-steffenhagen-diffblue]

Currently we set the CBMC version in config.inc.

It would be useful to have this information in our CMakeLists.txt as
well (especially for e.g. CPack packaging), and to avoid duplication it
would be better to have it in just one place. It’s somewhat easier to
parse config.inc from CMake than doing it the other way round (and we
already do it in src/util/CMakeLists.txt anyway), we do it here.

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[NlightNFotis]

LGTM, but I would appreciate a small comment on why we do it in the source - I know it's in the commit message, but something similar (smaller preferably) would be great to have in the code itself.

[codecov]

Codecov Report

Merging #5458 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #5458   +/-   ##
========================================
  Coverage    68.23%   68.23%           
========================================
  Files         1178     1178           
  Lines        97590    97590           
========================================
  Hits         66592    66592           
  Misses       30998    30998           

Flag	Coverage Δ
#cproversmt2	42.81% <ø> (ø)
#regression	65.40% <ø> (ø)
#unit	32.23% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8a99f23...f8cdbb0. Read the comment docs.

[chrisr-diffblue]

Generally looks good to me, and good to see this made consistent with the Makefile builds. A small query but not blocking.

[chrisr-diffblue]

Just a general query about this - when does config.inc get generated? IIRC it gets auto generated using the git info? If so, when does that change, and what is the effect here? I'm slightly worried about whether this means every time you make a local change and re-build, it also causes a fresh re-configure? And if so, doesn't that also mean a fresh re-download of minisat?

[hannes-steffenhagen-diffblue]

@chrisr-diffblue This string is static and currently only user set (plan is to autoincrement on release going forward). The git-tag string is also used but only for use in util/version.h, which uses both this info and the git-tag.

The reason we keep the two separate is to support builds from source packages and shallow clones. So this will not trigger frequent reconfigures.

As I believe I’ve mentioned before as well a long term goal of mine is for us to stop downloading things off the internet in our CMakeLists.txt at all and instead provide the dependency downloading/building stuff as a separate script.