build: generate buildinfo.txt for test logs

[vszakats]

Also:

• read buildinfo.txt from runtests.pl and dump it to the log.
• cmake: show CROSS target flag for cross-builds.
• cmake: add logic to detect arguments passed via the command-line.

It is meant to help filling out missing datapoints in the testclutch
matrix.

[bagder]

👍

[bagder]

BTW, a more traditional way to generate this file would be to have a buildinfo.txt.in template like curl-config.in and libcurl.pc.in.

[vszakats]

BTW, a more traditional way to generate this file would be to have a buildinfo.txt.in template like curl-config.in and libcurl.pc.in.

Yes, considered it. Upside is that the fields would be guaranteed to match between cmake and autotools, but they also use a slightly different set now, so I went for the simpler, looser approach. .in is also more involved with a new set of macro names, etc. ..I'll give it some more thought.

(Converting configurehelp.pm to .in seems like a clear tidy-up candidate though.)

[vszakats]

There is plenty of tweaking opportunity here:

• place buildinfo.txt to root instead of tests?
• perhaps dump buildinfo.txt in CI for jobs that don't run tests? (for debugging build, and debugging detection itself)
• also dump it early in CI? (Perhaps as part of the config.h dump step)
• align target flags to have a non-CMake-specific feel (lowercase them for example)
• try to bring the set of fields and their contents more in sync and consistent across autotools and cmake?
• tweak log output? (it's a tad verbose now) Perhaps hide it under a GHA log fold?
• tweak file format, field names?

I'd say it's largely good as it is for a start and we can tweak it as we go.

[dfandrich]

I've modified Test Clutch to use these new fields; you should start seeing them tomorrow. I found a couple of inconsistencies I'd love to see addressed, though:

• buildinfo.target is blank on cmake. If it can't be determined, the line need not be written
• buildinfo.compiler.version write the human-readable compiler version on CMake but an internal processed version on autoconf (e.g. 12.3.0 vs 1200). It would be nice to have both these be the human-readable versions, as the internal one probably isn't very interesting for anything to see. configure writes both the processed one and the "raw" one, which seems to drop the minor and patch versions. The important thing is for it to be more consistent, so "raw" would be better if there's no alternative.

Some fields are duplicates:

• buildinfo.host.os is the same as the "OS: " line (but possibly in a different form from a different source)
• buildinfo.{host,target}.vendor can be derived from buildinfo.{host,target} (when it exists, and it only exists when it is found)
• buildinfo.configure.os is (presumably) always the same as "OS: " or buildinfo.host.os

[vszakats]

@dfandrich: Thanks for the testclutch update and your feedback!

I'll see how to include the raw compiler version from autotools.

configure.os is CMake only, and shows the OS version, too. This may be useful in theory. With current jobs and tests, it's probably not overly relevant.

The rest is mostly caused by the different worldviews of the tools. With autotools host/target is always the same as cpu-vendor-os. With CMake, it's a bit all over the place. target is filled in a couple of jobs, but manually via CMAKE_C_COMPILER_TARGET. It seems safe to drop. For autotools, the individual cpu-vendor-os could be dropped in favour for target / host triplets.