Emscripten has not implemented adding shared libraries directly
to main modules properly yet.
See: https://github.com/emscripten-core/emscripten/issues/21667
Therefore, instruct libtool to use directory instead of the shared
object file for linking, as suggested in the issue.
The cross-compiled binaries are likely not going to be usable on the host and
should not be added to the PATH. They should never be used to be consistent
between native and cross-compiled builds.
It was added in the original build script: 5648ecad1a.
This is done in the other contribs. It helps figuring out what is built in one
place and also what is pulled as a dependency.
The last remaining build script not to do it is Android but there's a
pending patch: https://code.videolan.org/videolan/libvlcjni/-/merge_requests/88
Both `-emit-llvm` and a `.bc` output extension are needed to export
bitcode since emscripten 3.1.50[^1]. Otherwise a plain object file will
be created.
[^1] 94b36c04dd
Gitlab has some constraints[^1] regarding the cobertura output to have
the coverage results displayed on the merge request:
- Files in the diff view must appear in the cobertura file to have the
coverage enabled for them.
- <filename> must be absolute or <source> must typically have an
absolute path to the project directory.
- Pipeline must have completed to show the results.
- The coverage report must not exceed the limits (10MiB and 100
sources node).
The second point on absolute filename was not valid given that meson
gcovr setup the <source> with `.`, leading to the only <source> element
referencing `.` instead of ${CI_PROJECT_DIR}.
This commit patches the generated coverage to ensure it's relative to
the root directory, enabling diff coverage.
[^1]: https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html#test-coverage-visualization-not-displayed
The files are reported to gitlab but not made public. Being able to
download it enables running gcovr locally and makes it easier to debug
coverage issues.
When parsing the coverage with the Qt module enabled, gcovr was failing
to parse the output for qt5-vlc_qrc.cpp, leading to the following error.
$ gcovr -r build-meson --json gcovr.cov.json 130 ↵
(INFO) Reading coverage data...
(WARNING) Unrecognized GCOV output for /home/alexandre/workspace/videolabs/vlc-master/build-meson/modules/gui/qt/qt5-vlc_qrc.cpp
37:60736-block 0
37:60751-block 0
37:60759-block 0
37:60767-block 0
37:60768-block 0
This is indicative of a gcov output parse error.
Please report this to the gcovr developers
at <https://github.com/gcovr/gcovr/issues>.
(WARNING) Exception during parsing:
UnknownLineType: 37:60736-block 0
(WARNING) Exception during parsing:
UnknownLineType: 37:60751-block 0
(WARNING) Exception during parsing:
UnknownLineType: 37:60759-block 0
(WARNING) Exception during parsing:
UnknownLineType: 37:60767-block 0
(WARNING) Exception during parsing:
UnknownLineType: 37:60768-block 0
(ERROR) Exiting because of parse errors.
You can run gcovr with --gcov-ignore-parse-errors
to continue anyway.
(ERROR) Trouble processing 'vlc/build-meson/modules/libqt_plugin.so.p/meson-generated_.._gui_qt_qt5-vlc_qrc.cpp.gcda' with working directory '/home/alexandre/workspace/videolabs/vlc-master/build-meson'.
Stdout of gcov was >>File 'modules/gui/qt/qt5-vlc_qrc.cpp'
Lines executed:100.00% of 13
No branches
Calls executed:100.00% of 5
Creating 'qt5-vlc_qrc.cpp##1ea0d75896cd542c555451d8b8bb4a44.gcov'
Previously, it was trying to merge lines and triggered a negative hit,
leading to the introduction of the gcovr parameter:
--gcov-ignore-parse-errors=negative_hits.warn_once_per_file.
(INFO) - MainThread - Reading coverage data...
(WARNING) - Thread-29 (worker) - Unrecognized GCOV output for /builds/alexandre-janniaux/vlc/modules/codec/subsdec.c
branch 2 taken -1 (fallthrough)
This is indicative of a gcov output parse error.
Please report this to the gcovr developers
at <https://github.com/gcovr/gcovr/issues>.
(WARNING) - Thread-29 (worker) - Exception during parsing:
NegativeHits: Got negative hit value in gcov line 'branch 2 taken -1 (fallthrough)' caused by a bug in gcov tool, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68080. Use option --gcov-ignore-parse-errors with a value of negative_hits.warn, or negative_hits.warn_once_per_file.
(ERROR) - Thread-29 (worker) - Exiting because of parse errors.
You can run gcovr with --gcov-ignore-parse-errors
to continue anyway.
This option seems to still be needed since it is impacted by how
coverage is computed by GCC.
Issue #28490 also mentioned the following assertion:
AssertionError: Got function MainUI::getComponent() const on multiple lines: 26, 27.
You can run gcovr with --merge-mode-functions=MERGE_MODE.
The available values for MERGE_MODE are described in the documentation.
This assertion was due to --merge-mode-functions[^1] not being accounted,
which it now does in gcovr 7.0[^2], and files using Q_OBJECT and the MOC
code generator, duplicating some inline functions from headers.
class MainUI : public QObject {
Q_OBJECT
public:
/* The line below duplicates a function definition at two different
* locations because of MOC. */
inline QQmlComponent* getComponent() const {return m_component;}
We don't need this file to have its coverage checked since it's
generated from an XML file, so let's just ignore it from the coverage
entirely.
[^1]: https://github.com/gcovr/gcovr/pull/700
[^2]: https://github.com/gcovr/gcovr/pull/844Fixes#28533#28490
Running
./extras/ci/get-contrib-sha.sh debian-meson
is currently failing with:
fatal: empty string is not a valid pathspec. please use . instead if
you meant to match all paths
because "${VLC_BUILD_TARGET}" would count for an empty parameter, as
opposed to being discarded without quotes. In some shells, like zsh, it
would also count as a parameter regardless of the presence of the
quotes.
Instead of using an intermediate variable to store an optional path,
this commit directly adds to the bash array containing the path checked
to find the contrib ancestor, allowing to both submit multiple files if
necessary, or none if unnecessary.
Regression from 4ac6168d47.
For example, updating a Windows build script shouldn't force the macOS jobs to rebuild contribs.
By default the script behaves the same as before. It requires giving a job name or target OS name to
select the changes only for that OS.
The tests are all compiling on macos and most of them are running
correctly, so we can ensure they continue to build. We cannot try to run
them without ensuring we select the runner architecture first though.
Regression from 70c643090b.
Khalid Masum