Tests have been disabled since boost-1.55.0-r2, dating back to the initial ::gentoo git import. Revisit whether they are now more useful and/or runnable from the build. Reproducible: Always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119383 is a good motivating example for this.
Initial shots in the dark at: https://github.com/hhoffstaette/gentoo/commits/boost-tests/ The biggest problem is that I have no multilib systems to test. :)
Created attachment 924738 [details] Trimmed log of test run I wired up USE=test and noodled my way through multilib stuff, which I cannot really test (only no-multilib systems here), so for now I just run the tests for the best API - don't judge. After finding the right directory we just define a list of libraries to test and run their test suites, which signal success with return code != 0. Mutating a test to make it fail aborted properly.
(In reply to Holger Hoffstätte from comment #3) > which signal success with return code != 0. success -> failure of course.
Apart from the multilib issue I'm wondering how to find the list of libs that was built and/or will be installed. I *think* it's just the set of directories in $S-$<abi>/libs so if all else fails we can just collect them all and filter out a list of known-failing suites. b2 is mindblowingly bad.
For completeness btw, tests got dropped with: commit 443977c23782282c0c85e32403c2a11def452f8a Author: Diego Elio Pettenò <flameeyes@gentoo.org> Date: Wed Oct 31 16:32:26 2012 +0000 Unslotting. This removes a bunch of older packages that will not build on modern systems, keeps only three versions (stable, mostly-stable and masked). The new 1.51.0-r1 is designed so that it does not have to do any eselect or eselect-like trickery for the symlinks, also drops the tests (which are not working as expected anyway). (Portage version: 2.2.0_alpha141/cvs/Linux x86_64, signed Manifest commit with key 1CD13C8AD4301342)
Very progress, much wow! The current state is: - we have an exclusion list of test suites that fail (mpi and python are very questionable) - we have a list of tests that need patching with main() (workaround for boost.test running with shared libs) - we have support for full-test to enable (currently only) boost.geometry, which takes ~1h to compile. With debuginfo and static linking this blew up my 16GB tmpfs, but it succeeds in release mode with shared libs. - multilib support still needs addressing, help appreciated Maybe a draft PR to discuss?
(In reply to Holger Hoffstätte from comment #7) > Very progress, much wow! The current state is: > > - we have an exclusion list of test suites that fail > (mpi and python are very questionable) Yeah, I think having a reliable-ish testsuite is more important, especially given we.. know Boost and what it is like. Some coverage > none. I don't want us to be annoyed with very poor tests and end up ignoring failures. ) > - we have support for full-test to enable (currently only) boost.geometry, > which takes ~1h to compile. With debuginfo and static linking this blew up > my 16GB tmpfs, but it succeeds in release mode with shared libs. > Bikeshed alert: we decided to normalise on 'test-full' a few months ago. > - multilib support still needs addressing, help appreciated > > Maybe a draft PR to discuss? Sounds good. Thanks a lot for working on this.
It's important to note that boost itself does not seem to have a top-level test suite/runner as it's just a meta-distribution. All included libs very much have their own way of running tests (though consistently controlled by b2), with wildly different levels of quality. Some run silently, others barf endless amounts of failure logs and then "succeed" anyway.
(In reply to Sam James from comment #8) > Bikeshed alert: we decided to normalise on 'test-full' a few months ago. That's what I actually used - just a typo.
