Run the tests from CMake with explicit boost_test(); fix test failures; self-contained CI

[reach2sayan]

The purpose of the PR is to make the CI Green

From the start : boost_test_jamfile()only parses flatrun foo.cpp ;lines, so the bracketedtest-suiteintest/Jamfile.v2 was ignored and a CMake build with BUILD_TESTING=ON configured no tests.

As requested in review, this now lists the tests explicitly with boost_test() instead of flattening the Jamfile. Running the tests in more places exposed a few real failures, which are fixed here too, and CI is replaced with a self-contained version of the same jobs.

• test/CMakeLists.txt: explicit boost_test() calls for the same tests as the Jamfile. The Jamfile's strict floating-point flags are mirrored per compiler (/fp:strict for MSVC and clang-cl, -fp-model=strict for IntelLLVM, -frounding-math for GCC/Clang). msvc_x64_flags is built only for MSVC x64, and cmp_tribool` stays disabled (Changes in Boost.Logic (tribool) have broken compare/tribool #15).
  No language standard is forced, so C++03 builds keep working.

• test/Jamfile.v2: back to the original test-suite form. The only change is two added strict-FP requirements, <toolset>clang-win:<cxxflags>/fp\:strict and <toolset>intel:<cxxflags>-fp-model=strict. Without them pi fails on clang-win and overflow fails on icpx (which defaults to -fp-model=fast; it also fails on master).

• test/add.cpp: the symbolic expr nodes were never freed, so LeakSanitizer failed add. They are now owned by a small pool (C++03). The pool records the pointers, and just calls delete on them when it goes away.

test/suppressions.txt (leak:add) is removed as obsolete.

• test/cmp_exn.cpp: cast the BOOST_C_EXN operand to void to silence -Wunused-comparison.

• windows-11-arm: uses toolset=msvc without a version. GitHub is moving this runner to an image that ships only Visual Studio 2026, and while that happens repos get either VS 2022 or VS 2026, so a pinned msvc-14.3 or msvc-14.5 fails on one of them.
  The main issue is the Boost.CI could be a moving target? We have github.

the flags are necessary for the pi test.

[reach2sayan]

@Lastique You were the large person with a merge. So I tag you.
My background is in computational materials science - and I have been writing C++ for the past 3 years professionally at a chemical process simulations software company - NJ USA.

I wanted to build up a Open Source footprint - especially in the maths domain - since I use a bunch of those libraries and inevitably would use more.

I made this low-key change, mostly as an excuse for this intro (usefull though).
I'm on vacation next week, but would soon get up to speed with the basic idea, I would take any criticism and mentorship.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.00%. Comparing base (2939307) to head (9b0af95).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop      #49   +/-   ##
========================================
  Coverage    78.00%   78.00%           
========================================
  Files           22       22           
  Lines          923      923           
  Branches       364      373    +9     
========================================
  Hits           720      720           
  Misses         196      196           
  Partials         7        7           

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2939307...9b0af95. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Lastique]

I'm not a maintainer of this library, but if you want my opinion, I'm not a fan of using boost_test_jamfile in any cases but trivial. That is, if there are compiler-dependent flags or conditions (such as for msvc_x64_flags.cpp) or linking special libraries, or really anything special about the tests, I would rather have CMakeLists.txt list the tests, along with their specifics, in it. Something along these lines. I really don't like relying on boost_test_jamfile doing a reasonable conversion when it doesn't recognize b2 specifics.

Anyway, I approved the CI run and it currently fails. Not sure what's going on there as the library uses Boost.CI, which I don't know how it works.

[reach2sayan]

@Lastique So who is the maintainer? I could try to figure this CI issue out - if that's of interest. Also the general maintenance of the library. Many orphaned PR.

About CI The idea would be to what others do. I am very new to this. But in any case would any of the CI stuff need elevated permission of sort? But again only if it's of interest.

Just pointing me to the the right person would be helpful.

[reach2sayan]

The sanitiser run fails with leaks - also an issue

[Lastique]

The official maintainers are listed in meta/libraries.json, although it doesn't look like they have been active recently.

We are, of course, interested in submissions, including in CI cleanup. I have the permission to merge the PR, but given that I'm not a maintainer and I'm not familiar with the library, the PR would have to be easy to understand, and it should pass CI.

About CI The idea would be to what others do.

Well, everyone is doing what makes sense in their libraries. As I said, in trivial cases boost_test_jamfile would do, but here I would rather use boost_test and explicitly specify all tests in CMakeLists.txt.

[reach2sayan]

@Lastique Could you please release the CI. I tried to fix the tests, I tried on my fork, everything except codecov passed.

And then comment on the ymls. Do you think it might be too much for a single PR? I tried to keep the ymls separate.

[Lastique]

I generally prefer a single ci.yml that does all the testing. Otherwise, CI generates too much spam. I didn't look in the ymls themselves, but it looks like a lot of changes.

[reach2sayan]

@Lastique so the last issue was a msvc version, there is a warning about it, I suspect pin wasn't a good idea (for now on arm). Rest all passed, but run the windows runner first - If success the rest (they had passed once)

[reach2sayan]

I generally prefer a single ci.yml that does all the testing. Otherwise, CI generates too much spam. I didn't look in the ymls themselves, but it looks like a lot of changes.

that's true - I merged the yml files. Running the very first one should just suffice

[Lastique]

Thanks.