Add support for modular build structure. #1160
Conversation
…a source in install targets.
|
Please review and merge this PR at your earliest convenience. |
|
@grafikrobot There's a lot of failures here, for example: That test, and all the float128 tests are predicated on: And that configure step is showing "no" and so should NOT be building? |
|
Hm.. Strange.. Will investigate. |
…build is a non-free feature. Which can't be acquired through a usage requirement.
|
@grafikrobot thanks for the fixes, however there are still configuration related failures, for example if we stick to this job: https://drone.cpp.al/boostorg/math/2055/66/2 then the first failure is a linker error for test_2F0 - it's looking for libquadmath which isn't present. The Jamfile for that target has: and the configuration output says: But it's still trying to link against it. There are other configuration failings as well, that's just the first one in the log. Thanks! |
Fix igamma_large support on device Add GPU support to toms748 Add GPU support to igamma_inv Add GPU markers to gamma_inva Add GPU Markers to lgamma_small Remove STL usage from gamma Remove NVRTC workaround Fix fraction use of STL headers Mark gamma functions in fwd Disable declval on all GPU platforms Disable more unneeded code on device Add forward decl for NVRTC tgamma Disable unneeded items for all GPU Change workaround for missing overloads Rearrange definition location Add include path to cuda now that workaround is removed Fix NVRTC incompatibility with recursion and forward decls Add tgamma_ratio CUDA and NVRTC testing Fix NVRTC handling of gamma_p_derivative Add gamma_p_derivative CUDA and NVRTC testing Remove recursion from gamma_incomplete_imp Add SYCL testing of igamma, igamma_inv, and igamma_inva Ignore literal-range warnings Remove use of static const char* for function name Fix missing CUDA header Remove calls under NVRTC to fwd decl Add more nvrtc workarounds Use builtin erfc instead of header cycle Add CUDA and NVRTC testing of gamma_p_inv Adjust tolerances Add GPU support to chi squared dist Fix static local variable Add chi squared dist SYCL testing Add chi squared dist CUDA testing Add chi squared dist NVRTC testing Add GPU support to weibull dist Add weibull dist SYCL testing Add weibull dist CUDA testing Add weibull dist NVRTC testing
|
@jzmaddock I think I failed to understand how you are doing those checks. And actually I'm still failing. :-) What I tried to do was to normalize/abstract the various float18 config checks into one variable for reuse. But I didn't notice you use the checks differently in various places. So let me ask this.. In one place you use: And in another you use: Note the missing
|
|
@jzmaddock AFAICT the issues with quadmath are now resolved. But it would be great to get an answer on the consistency question of the trio of float128 checks. Or rather, on the lack of consistency in the many places those are copy+pasted which I fixed? |
|
Apologies Rene, no they are not consistent, and no they are not really meant to be, each test has it's own set of requirements, some of them are "if this is available link to it because a dependency needs it", some are "if this is available enable testing" and so on. Plus it's not just the float128 configurations that are failing: I highlighted that because it was the first and most numerous thing to show up, but there are others as well as I think. |
Or perhaps not as this appears to be green now. In principle though, shouldn't each conditional usage be able to define it's own set of requirements depending on what that target needs? |
In principle you can do whatever you like depending on what you need and intended. And it's precisely your INTENT that I'm asking about because I definitely do not know what math testing needs to do. I'm just guessing to what I think you might have intended. So to reformulate the question.. Here are the variations of the use of the Question is.. Did you intend to make all those different? Or should they be uniform and it's a historical mistake that they differ? Do note that I only rewrote the cases of Also, generally, the reasons to specify what those checks are in a simple place near the top of the jamfile are:
Further note.. Those are not the only copy+pasted HTH |
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #1160 +/- ##
===========================================
- Coverage 94.09% 93.77% -0.32%
===========================================
Files 780 654 -126
Lines 65851 53718 -12133
===========================================
- Hits 61960 50375 -11585
+ Misses 3891 3343 -548
... and 180 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
|
This is effectively green now with only Codecov failing. Based on the massive diff stat shown in the codecov comment it looks like something went wrong parsing an upload since all of those runs are green. Anything else @jzmaddock before I squash and merge this? |
This is part of the effort to make the Boost libraries "modular" for build and consumption. See https://lists.boost.org/Archives/boost/2024/01/255704.php and https://github.com/grafikrobot/boost-b2-modular/blob/b2-modular/README.adoc for more information.
This PR depends on the following other PRs being merged to both develop and master branches of the respective repos:
This PR will be changed to ready for review, i.e. not draft, when the above are merged. Do not merge this one until that time.