The CDDB databse from freedb.videolan.org doesn't reply anymore (due to
MusicBrainz ?). freedb.org is dead and gnudb.org is empty.
We still have MusicBrainz which is better.
The one reason it may still work for some is that they run their own server.
And the CDs they have are not found in MusicBrainz.
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