Otherwise we end up with warnings like this:
> ld: warning: object file (vlc/build/modules/isa/aarch64/simd/.libs/merge.o) was built for newer 'macOS' version (15.0) than being linked (11.0)
https://code.videolan.org/videolan/vlc/-/merge_requests/7297#note_495217
moc is indeed missing some include paths. It is called like:
```
moc .... -I/usr/include/QtQuickControls2 -I/usr/include/QtQuick/6.8.3
-I/usr/include/QtQuick/6.8.3/QtQuick -I/usr/include/QtQuick ...
```
but it doesn't includes /usr/include, so when we run moc with --debug-includes we can see that /usr/include is not considered for the header search paths, so most of the includes fails
here when searching QtQml/qqml.h included by QQmlEngine
```
debug-includes: searching for 'QtQml/qqml.h'
debug-includes: considering '/home/pierre/workspace/vlc/include/QtQml/qqml.h'
debug-includes: considering '../../../include/QtQml/qqml.h'
debug-includes: considering '../../../QtQml/qqml.h'
...
debug-includes: considering './dialogs/vlm/QtQml/qqml.h'
debug-includes: considering './QtQml/qqml.h'
debug-includes: considering '/app/include/QtQml/qqml.h'
debug-includes: can't find 'QtQml/qqml.h'
```
the moc include paths are currently extracted by the script
modules/gui/qt/scripts/static_dirs.py which parse a Makefile generated by
qmake. here the INCPATH variable doesn't contains /usr/include/ likely because
this is already part of $QMAKE_DEFAULT_INCDIRS, qmake's moc call include this
automatically (see /usr/mkspecs/features/moc.prf)
So we need a way for static_dirs.py to either extract $MOC_INCLUDEPATH or
$QMAKE_DEFAULT_INCDIRS.
The presence of the header file is not sufficient. We need to test the
library too, like we do in other similar cases.
This fixes building with cross-compilers and shared include directories
(e.g. on Debian).
protoc 3.4.1 reports using libprotoc 3.4.0 instead of 3.4.1.
That's the only release before 3.22 with a minor release version not
reported properly by protoc. After that we get the proper report:
- libprotoc 3.19.5
- libprotoc 3.12.4
- libprotoc 3.6.1
- libprotoc 3.5.1
And before 3.4.1 there were no minor 3.x release versions.
Versions 3.1 to 3.22 are considered to version 1 to 22. 3.22.x then switched to 22.x.
Avoids grabbing warnings on invocation of the target compiler, e.g.
#define VLC_COMPILER "clang: warning: argument unused during compilation: '-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk' [-Wunused-command-line-argument]"
Signed-off-by: Claudio Cambra <developer@claudiocambra.com>
So we don't rely on possibly outdated headers from a previous installation.
The variables in libplacebo have been around since [^1] which is in version 3.104.0
and above. We require version 4.192.
[^1]: 98b92cd6b4
The behavior may be different when qmake
generates the build files depending on
the build mode.
For example, with MinGW-w64 `-Wl,-s` (which
stands for stripping symbol information) is
added to the linker flags if build mode is
(directed or assumed to be) release.
If debug mode is not enabled, the default
behavior is retained, which appears to be
release. I specifically did not request
release mode when debug is false, because
debug being false does not necessarily mean
release.
When the protoc version is in the a.b.c format the protobuf version
is in the a.b.c.d format. Some version of pkg-config allow the equality
of the two, but not all.
We can just make sure protobuf is between a.b.c and a.b.(c+1).
Fixes#29066
Emscripten is known to deal badly with function casts to incompatible
types [^1]. This patch prevent us to accidentally merge harmful UB casts
to wasm enabled code. The warning is really strict but is compliant to the
standard. Code that wants to use function cast should be disabled from
the wasm platform.
[^1]: https://emscripten.org/docs/porting/guidelines/function_pointer_issues.html
Starting with Qt 6, RCC uses zstd by default. If Qt is
built without zstd, it does not have the ability to
decompress zstd.
This is mainly a problem when host tools are outsourced.
For example, currently we don't provide zstd to Qt in
the contribs, so it does not support compressing (rcc)
or decompressing (libqtcore) zstd. However, the script
that determines the host tools only check for version
and does not check for feature mismatch (contrib/main.mak).
Not only that, it also prioritizes the system than the
contribs even if tools exist in the contribs.
Because of this reason, host tools are picked from the
system. In my case, my system RCC was built with zstd
support, so it uses zstd compression by default. However,
contrib Qt does not support zstd.
If this occurs with static Qt, it leads to build failure
due to undefined reference. If this occurs with dynamic
Qt, I assume that it would cause runtime error.
Qt's officially supported build systems seem to already
check if Qt supports decompressing zstd and adjust the
rcc invocation (mkspecs/features/resources.prf). In this
patch, I propose doing the same for our unofficial
Autotools and Meson build systems for the Qt module.
qmake doesn't provide the proper contrib QT_VERSION when using
a -qtconf. It provides the version it was compiled with (!).
So we use the one from contribs if possible.
LLVM(18) doesn't support this option in any language.
GCC warns that this is not supported in C++ but autotools and meson consider it's supported.
Fixes this warning:
> cc1plus: warning: '-Werror=' argument '-Werror=return-mismatch' is not valid for C++
Steve Lhomme
Pierre Lamot
Rémi Denis-Courmont
Fatih Uzunoglu
Claudio Cambra
Brad Smith
Thomas Guillem
Alaric Senat
Tristan Matthews
AsciiWolf