It is brittle to silently ignore Cmake warnings in the CI.
They should be turned into errors.
This will uncover an issue in the centos task that the correct python version is missing. I guess this should be fixed by installing and activating an acceptable python version.
It is brittle to silently ignore Cmake warnings in the CI.
They should be turned into errors.
When building with Berkeley DB > 4.8, this warning will be always emitted: https://github.com/bitcoin/bitcoin/blob/78f1bff7099b854bb71e57d0307b8c21a1ac32c5/CMakeLists.txt#L107-L109
I guess I was mostly thinking about configure_warnings.
An alternative would be to require python to be disabled explicitly. Otherwise, it seems odd that every setting in cmake has a static default that can only be overridden explicitly, except for some, which are silently downgraded?
This will uncover an issue in the centos task that the correct python version is missing. I guess this should be fixed by installing and activating an acceptable python version.
It is brittle to silently ignore Cmake warnings in the CI.
I think the desire to turn warnings into errors on CI (both configure warnings and build warnings) is due to the fact that CI does not perform any analysis of the build output. If the build result was displayed on a dashboard, you would not want to turn warnings into errors, because it would take away useful statistics. Turning warnings into errors is the wrong approach. Consider how the following information would look like with warnings turned into errors.
0configure warnings: 3
1configure errors: 0
2build warnings: 14
3build errors: 2
4tests failed: 10
5tests passed: 2342
6tests skipped: 27
Turning warnings into errors is the wrong approach.
The thinking behind this is that all warnings should be addressed in one way or another, otherwise there wouldn’t be something to warn about.
One way to achieve this is by turning warnings into errors and then addressing the errors.
As for errors: It is not possible for errors to exist, because pull requests will not be merged when errors exist in the CI.
It is not possible for errors to exist, because pull requests will not be merged when errors exist in the CI.
This is just a matter of configuration. The same mechanism that prevents merging when errors exist could be used to prevent merging when warnings exist.