Closed tim77 closed 3 years ago
Already fixed by using system doctest in #43.
Similar issue with wayfire
build should be fixed by updating bundled wf-touch
to https://github.com/WayfireWM/wf-touch/commit/8974eb0f6a65464b63dd03b842795cb441fb6403
If you don't mind i'd reopen issue since we still have a problem with tests, but now on 32-bit arches like i686
and armv7hl
.
+ /usr/bin/meson test -C i686-redhat-linux-gnu --num-processes 48 --print-errorlogs
ninja: Entering directory `/builddir/build/BUILD/wf-config-0.7.0/i686-redhat-linux-gnu'
ninja: no work to do.
1/10 Types test OK 0.03s
2/10 OptionBase test OK 0.03s
3/10 Option test OK 0.02s
4/10 Option wrapper test OK 0.02s
5/10 Section test OK 0.02s
6/10 XML test OK 0.02s
7/10 ConfigManager test OK 0.02s
8/10 Log test OK 0.01s
9/10 File parsing test OK 0.31s
10/10 Duration test FAIL 0.37s exit status 1
>>> MALLOC_PERTURB_=147 /builddir/build/BUILD/wf-config-0.7.0/i686-redhat-linux-gnu/test/duration_test
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
[doctest] doctest version is "2.4.5"
[doctest] run with "--help" for options
===============================================================================
../test/duration_test.cpp:12:
TEST CASE: wf::animation::duration_t
../test/duration_test.cpp:19: ERROR: CHECK( duration.running() == false ) is NOT correct!
values: CHECK( true == false )
../test/duration_test.cpp:20: ERROR: CHECK( duration.progress() == doctest::Approx{1.0} ) is NOT correct!
values: CHECK( -9392801.5 == Approx( 1.0 ) )
===============================================================================
[doctest] test cases: 3 | 2 passed | 1 failed | 0 skipped
[doctest] assertions: 56 | 54 passed | 2 failed |
[doctest] Status: FAILURE!
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Summary of Failures:
10/10 Duration test FAIL 0.37s exit status 1
Ok: 9
Expected Fail: 0
Fail: 1
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Ah, that's a funny one: duration_t::impl::is_ready
assumes that get_elapsed
on freshly initialized object will return sufficiently large positive number. That works on 64-bit architectures, as now() - 0
fits into 64-bit long
. That also fails on all 32-bit architectures as the value overflows 32-bit long
type and becomes negative.
I guess get_elapsed
should be returning std::chrono::milliseconds::rep
.
Ah, that's a funny one:
duration_t::impl::is_ready
assumes thatget_elapsed
on freshly initialized object will return sufficiently large positive number. That works on 64-bit architectures, asnow() - 0
fits into 64-bitlong
. That also fails on all 32-bit architectures as the value overflows 32-bitlong
type and becomes negative.I guess
get_elapsed
should be returningstd::chrono::milliseconds::rep
.
Nice find, we could also just return int64_t, I am not a fan of such long types :)
In Fedora 34 compiles fine, but build error in f34. GCC version basically identical -
11.0.1
.11.0.1
0.56.2
0.57.2