0.9.0 --- a build can state which version of this library it holds

[Sunrisepeak]

Two rounds of mcpplibs/openkal-linux#13 were answered against the wrong version, and the software gave no way to settle the question.

The only version-shaped thing a program could read was uname's release field, which was the string literal "0.5.0" through every release after 0.5.0. That is not a missing answer but a wrong one — a consumer who checked it was misled rather than left uncertain.

What changes

build.mcpp reads the version from mcpp.toml and defines it. The number is stated in one place: a defines entry in the manifest would state it a second time, four lines below where it already is, and the two would agree until one of them was edited. A manifest the program cannot read yields no definition, and the field then reports unknown — a true statement, unlike the constant it replaces.

• uname's release field is that version.
• OPENKAL_MUSL_TRACE=enosys names it before the program runs, and whether or not anything is missing:

openkal-musl 0.9.0
openkal-musl: no operation for system call 266

That last part is the substance rather than a detail. A run in which nothing was refused printed nothing at all, so three situations were one reading: the version is right and no operation is absent; the variable did not take effect; this is not the binary the reader thinks it is. The report that began that round could not distinguish them, and neither could we.

One process contributes one such line, so a program that starts another produces one for each and they must agree.

Criteria

Three, and the third is the one that protects everybody who is not debugging:

  ok  silent unless asked
  ok  the banner names 0.9.0
  ok  uname reports 0.9.0

Without the third this feature would be free to become noise in every ordinary run and nothing would say so. Measured: with the variable unset the probe writes zero bytes to the error stream.

Confirmed by putting the previous behaviour back:

banner:  FAIL  got=[]
uname:   FAIL  got=[0.5.0]

examples/posix asserts the field is neither empty nor the placeholder, and deliberately does not assert a particular number — an observation naming one would have to be edited by every release rather than checked by it. The workflow is what compares the number against mcpp.toml.

The quoting, because it failed first

-DOKM_VERSION="0.9.0" reaches a build file that a shell executes, so the compiler received -DOKM_VERSION=0.9.0:

<command-line>: error: too many decimal points in number

naming a line in build.mcpp that was correct. The escape is what the shell removes now, and the quote survives.

What a program above this observes

⚠️ The release field moves at every release. Nothing here or in musl reads it — gethostname and getdomainname are musl's only consumers of uname and both read nodename — but a program that compares the field against a fixed string will see it change. sysname is openkal and not Linux, so nothing can have been reading it as a kernel version. Recorded in README.md's divergence table.

Nothing else changes: 49 observations, 0 failures.