Boris Kolpackov wrote:

Peter Dimov via Boost writes:

...

Because Boost.Compute (boost/compute/detail/sha1.hpp) uses an implementation detail of Boost.UUID (boost/uuid/detail/sha1.hpp), and because I changed the implementation to fix an endianness issue, now causes a compile error in 1.86.0

Any sense why this was not detected (e.g., by CI) when the change was made or during pre-release testing? It seems to me compiling any translation unit that included would have picked this up, no?

It would have, but no such translation unit was compiled by anyone before the release went out. There's no CI that runs the entire Boost test suite (that would take many hours) but even if there were, Boost.Compute's tests require OpenCL and automatically disable themselves when it's not present. This is why, in principle, we do a beta release, to catch these issues before the real release, but it doesn't seem to be effective.

Peter Dimov writes:

Boris Kolpackov wrote:

...

Any sense why this was not detected (e.g., by CI) when the change was made or during pre-release testing? It seems to me compiling any translation unit that included would have picked this up, no?

It would have, but no such translation unit was compiled by anyone before the release went out.

There's no CI that runs the entire Boost test suite (that would take many hours) but even if there were, Boost.Compute's tests require OpenCL and automatically disable themselves when it's not present.

This is why, in principle, we do a beta release, to catch these issues before the real release, but it doesn't seem to be effective.

I've been thinking about this for some time now so maybe now is a good time to bring it up: as you may know, we've packaged most[1] of Boost libraries for build2 (as individual packages) and are building them continuously on our CI, which covers all the major platforms and compilers (there is currently a 100 distinct build configurations[2]). Currently, we package releases, usually waiting for some time for any bugs (like this one) to shake out. But we could do that during the Boost pre-release stage to help detect any regressions if the Boost community would find this helpful. Specifically, all the build results are stored in an SQL database and we can easily run queries like "compare all build results between these two versions of Boost and list discrepancies" or "compare, say, Clang 18 build results to Clang 19 and list discrepancies", where the discrepancy can be errors but also warnings[3]. So, concretely, before a release, we could produce a report that lists Boost libraries that used to build in a specific build configuration but which no longer do so (and which likely indicates a regression). Now, there are a couple of "catches": Firstly, we haven't yet ported each library's tests to build2. Instead, for each library we have a smoke test that includes all the public headers, and, for non-header-only libraries, also calls some non-inline functions (to make sure the built library is linkable). This should at least cover things like compilation errors and unresolved symbols. Secondly, updating our Boost packages to the next release takes some time, depending on the extent of changes (if there are new libraries, then we need to port them, etc). Likewise, it will take some time (days) to build everything on our CI. Currently, we have 7K builds per Boost version[4]. Putting theses two together, we will need at least a couple of weeks head start. Of course, ideally, one wouldn't want to wait until the release to detect such regressions, instead staging a snapshot of Boost throughout the development window. But that would require quite a bit more effort from our side and also consume quite a bit of our CI resources. But we could consider doing this if there is funding/help (we can do the before release check for free/ourselves). [1] The list of excluded libraries (and the rationale for excluding them) can be found here: https://github.com/build2-packaging/boost/blob/master/exclude Ironically, this list includes libboost-compute for the same reason: OpenCL dependency. But this can be addressed if desired by using a system-installed version of OpenCL (in build2 we have system package manager integration for Debian and Fedora- derived distributions). It will mean we only test libboost-compute in a small subset of build configurations, but it's better than nothing. [2] https://ci.cppget.org/?build-configs [3] We use a similar approach to test for regressions in build2 itself. That is, we rebuild all the packages in the repository with the staged version of build2 and compare the result to the released version. Currently this is done by crafting and running an SQL query but in the future we plan to add a web interface for diff'ing build results. [4] https://cppget.org/?builds=libboost-*&pv=1.83.0

Ruben Perez writes:

...

Currently, we package releases, usually waiting for some time for any bugs (like this one) to shake out. But we could do that during the Boost pre-release stage to help detect any regressions if the Boost community would find this helpful.

Does this happen for all libraries, all releases? cppget.org seems to list 1.83 as Boost.MySQL latest version.

We currently package every second version of Boost due to the lack of resources (1.85.0 is pending review and should be published shortly).

вт, 27 авг. 2024 г. в 00:46, Alexander Grund via Boost :

Some time ago I suggested that b2 supports compiling binaries but not running them. Not sure if this was implemented by now.

If you mean, disable running all or some tests, then there's testing.execute feature. To disable running all tests (e.g. when cross-compiling) you'd do b2 testing.execute=off To disable running a specific test in a specific situation you'd put in a jamfile something like run mytest.cpp : requirements <target-os>windows:off ; But regardless of that, as far as I can see, using Boost.Compute requires OpenCL to be present.

Hi all What about the following idea: We introduce a macro, something like "BOOST_COMPUTE_COMPILE_WITHOUT_OPENCL". In Boost.Compute we check for this macro, and when it is set we include a new stub headerfile instead of the regular OpenCL headerfile. The stub headerfile should contain all the necessary definitions so that Boost.Compute can be compiled, even when OpenCL is not actually installed. That would be step one and would make it possible to find at least non-compatible changes in the other Boost libraries. Step two would be to enhance the stub file so that the test programs also run without error. I can't say yet if this would even be possible, and how big the effort would be for that. Best regards René Am Di., 27. Aug. 2024 um 12:09 Uhr schrieb Alexander Grund via Boost < boost@lists.boost.org>:

Am 27.08.24 um 04:14 schrieb Дмитрий Архипов via Boost:

...

If you mean, disable running all or some tests, then there's testing.execute feature. To disable running all tests (e.g. when cross-compiling) you'd do

b2 testing.execute=off Yes that is what I was referring to, thanks! But regardless of that, as far as I can see, using Boost.Compute requires OpenCL to be present.

I see so it IS a hard requirement. Maybe we could have an option (possibly even in B2) to have a "<build>no" alternative that errors when triggered. E.g. `b2 testing.execute=off require-compute=on` (or even `require-all`)

This could then be used to do this build testing by release managers on a machine/VM/image that has all dependencies and avoid silently skipping some build tests if one is missing.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- “Dubito ergo cogito; cogito ergo sum. (I doubt, therefore I think; I think therefore I am)” René Descartes