Before:
test-zigc: run libzigc unit tests (part of test-modules)
test-libc: run libc-test cases
Now:
test-libc: run libc API unit tests (part of test-modules)
test-libc-nsz: run libc-test cases
libc API unit tests (previously referred to as libzigc unit tests) now run for all supported targets, even those we don't provide libzigc for. The idea is that this will help us catch bad assumptions in the unit tests, as well as bugs in other libcs.
I considered this setup:
test-c: run libc API unit tests (part of test-modules)
test-libc-nsz: run libc-test cases
test-libc: both of the above
However, I do not like it because it gives a false sense of security; the full module and C ABI test suites are still liable to catch libzigc bugs that test-c and test-libc-nsz might not. So contributors should just run the test steps outlined in #30978 (which will be updated after this PR is merged).
Before:
* `test-zigc`: run libzigc unit tests (part of `test-modules`)
* `test-libc`: run libc-test cases
Now:
* `test-libc`: run libc API unit tests (part of `test-modules`)
* `test-libc-nsz`: run libc-test cases
libc API unit tests (previously referred to as libzigc unit tests) now run for all supported targets, even those we don't provide libzigc for. The idea is that this will help us catch bad assumptions in the unit tests, as well as bugs in other libcs.
I considered this setup:
* `test-c`: run libc API unit tests (part of `test-modules`)
* `test-libc-nsz`: run libc-test cases
* `test-libc`: both of the above
However, I do not like it because it gives a false sense of security; the full module and C ABI test suites are still liable to catch libzigc bugs that `test-c` and `test-libc-nsz` might not. So contributors should just run the test steps outlined in #30978 (which will be updated after this PR is merged).