The goal is not to replace a build system. You don't need 25 configs or special cases. the goal is to provide a way for arc to build to it can run unit tests.

OK the goal is to check for bans when the error is EVAL_FALSE.

Se comments in the spec PR.

The purpose of this test is to test activation. This isn't the right place for test vectors.

Is that possible to remove the dependency from that test so that it test current behavior, then add the change required to the test to test the new behavior in D2645 ? This way it is very apparent what behavior is changed.

You will end up using the ui generator from the system even when not wanted (for instance for reproducible builds) with that construct.

See https://reviews.bitcoinabc.org/D2777#65449

The test case do not seem to be corresponding to the modified code (which is an assertion failing).

This will fail if the code if subsequently formatted, which should be fairly common. The test plan should definitively address this. I'm also not convinced this won't fuck everything up when run in parallel with other linters or test runners. If nothing else, it will dirty all builds.

The backports looks good, however the next test+bugfix really belongs in its own diff.

So if they have a fix, why not backport it ?

Overall it looks good, but there are discrepencies with the original code that need to be explained and possibly missing backports.

Does the problem exist in Core ?

I trust this is corect :)

I don't see what goal this is achieving.

You removed parallelism for no good reason.

Can you please add release notes about this ?

Why isn't it a linter?

See comment on D2743

Having the list is not a problem. Without the list there are no way for cmake to track dependencies properly, so it must either assume the worse or miss some.

If ourId is accessed concurrently by several threads, then this doesn't fix the problem. If it isn't then what is this fixing? I don't see any description of the problem that lead me to think this solution actually fixes anything.

The test plan doesn't test the behavior change and there is no test. Why is that getting accepted and merged ?

This looks good on the surface, but I need to do another pass of review to make sure.

There was a backport from core that did something very similar. While I do think the design of this patch is better than the one from core, I'd be hesitant to go for it as we'd have to maintain it rather than letting core handle that one.

I doesn't looks like you know what the problem actually is, and therefore you have no way to know if the solution is appropriate (and I do not either).

Things have been reordered for no apparent good reason. That just makes the review difficult.

Please provide a detailed test plan. Running the tests is not sufficient as this specific test is not ran by default.

Unless there is a larger plan here, this is just moving away from core without any clear benefit.