ossia / libossia / 32543709004
53%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 495
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 50.863% (+0.007%) from 50.856%
32543709004

push

github

jcelerier 
build: stop enabling Asio separate compilation without an implementation

On Windows, a shared build defined BOOST_ASIO_DYN_LINK=1 for every
compiler. That macro, like BOOST_ASIO_SEPARATE_COMPILATION, turns off
Asio's header-only default, so the separately compiled part of Asio has
to come from somewhere. It only ever did on MSVC: src/ossia/context.cpp
includes <boost/asio/impl/src.hpp> under _MSC_VER, and so do score's four
puppet executables.

With mingw-w64 the macro was therefore switched on while no translation
unit compiled the implementation, and every Asio entry point that is not
inline went undefined - 16467 references when linking libossia_x64.dll on
MSYS2 UCRT64. Nothing had caught it because the reference build dirs were
incremental, and libossia's sources do not change often enough for ninja
to relink the DLL.

Boost 1.91 only made it legible: BOOST_ASIO_ENABLE_VERSION_NAMESPACE
places the missing symbols in an inline namespace tagged with the Asio
configuration, so the diagnostics name boost::asio::v103801_bdemn::
rather than boost::asio::. The tag matches on both sides of the link -
the symbols are missing, not mismatched.

Move the definition into the MSVC branch next to
BOOST_ASIO_SEPARATE_COMPILATION, so the macros and the src.hpp include
agree. Non-MSVC Windows goes back to Asio's header-only default; MSVC is
unchanged.

29320 of 57645 relevant lines covered (50.86%)

184080.28 hits per line

Coverage Regressions

Lines Coverage ∆ File
1
87.5
0.83% src/ossia/dataflow/exec_pool.hpp
1
65.97
-0.69% src/ossia/network/sockets/websocket_server.hpp
Jobs
ID Job ID Ran Files Coverage
1 32543709004.1 495
50.86
GitHub Action Run
Source Files on build 32543709004