Remove redundant feature checks on re-run of CMake config step

[theComputeKid]

• On a config re-run, CMake will not check features again as it will read previously defined cache variables
• Logic was difficult to follow, so refactored cxx_feature_check for simplicity

On CMake config first run:

Before (slow): checks all REGEX engines
After (fast): short circuits on first REGEX engine found.

On CMake config re-run:

Before (slow due to checks):

-- Google Benchmark version: v1.9.4, normalized to 1.9.4
-- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_STEADY_CLOCK -- success
-- Performing Test HAVE_PTHREAD_AFFINITY -- failed to compile

After (fast as checks skipped): No output (as checks not performed)

Fixes #2078

[theComputeKid]

@LebedevRI: Can you please re-trigger the CI? Is github having network issues?

error: failed retrieving file 'dos2unix-7.5.3-1-x86_64.pkg.tar.zst.sig' from ftp2.osuosl.org : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds

MacOS might have a genuine failure but Windows is having these issues.

Edit: Fixed MacOS failures by removing -D from add_compile_definitions(). Older versions of CMake do not automatically remove the -D.

[theComputeKid]

It seems that there are intermittent failures already crept into main:

• https://github.com/google/benchmark/actions/runs/19699373022/job/56431605632
• https://github.com/google/benchmark/actions/runs/19572747967/job/56050049575

A quick look at the build-and-test workflow indicates that the pipeline is already failing tests that are showing up here as well on msys2, with the same user_counters_test or user_counters_test_tabular failing sporadically.

Based on this evidence, I believe that the failures are unrelated.

@LebedevRI: Can you please merge this and are the sporadic failures in main going to be investigated?

[LebedevRI]

Is this AI-made?

[LebedevRI]

Why?

[theComputeKid]

Why what?

[LebedevRI]

Since the line is only on the LHS of the diff, why this line and the other snippet being removed.
This literally renders this whole check pointless, since we no longer communicate it's results.

[theComputeKid]

I am not sure what you mean as the CACHE token here is communicating results at the parent scope:

set(${VAR} TRUE CACHE BOOL "" FORCE)

No other variables need to escape the function scope.

[LebedevRI]

https://github.com/google/benchmark/blob/2279f2acc8f2ca1bb51195a12966411bed31b26b/src/re.h#L22C14-L49

[theComputeKid]

Yes, HAVE_STD_REGEX, HAVE_GNU_POSIX_REGEX or HAVE_POSIX_REGEX are being properly propagated in my patch, depending on which REGEX engine is detected. If it wasn't, that file wouldn't compile with my changes and CI would fail.

As an example, in my local machine, it detects HAVE_STD_REGEX and does the right thing.

I am not sure I see the issue.

[LebedevRI]

Yes, HAVE_STD_REGEX, HAVE_GNU_POSIX_REGEX or HAVE_POSIX_REGEX are being properly propagated in my patch, depending on which REGEX engine is detected.

cmake cache variables - sure.

Preprocessor defines - no, they are not.
Could you please point me at where they are being set.

The answer i was looking for was: "are you illiterate or something, just on the line above, there's add_compile_definitions()".

If it wasn't, that file wouldn't compile with my changes and CI would fail.

This is not quite true, as you can see from that snippet, it has fallback defaults.

[theComputeKid]

Is this AI-made?

No.

[LebedevRI]

I think this is probably fine.
@theComputeKid thank you!

[LebedevRI]

@theComputeKid Fix reverted in #2127.