There is no more deprecated functions.
In case, we need to deprecate new functions in a future release, we can
just add LIBVLC_DEPRECATED, and leave the function in its original
header.
The tests are not run and are only compiled to object, without linkage.
It's pretty fast, and would help noticing when a forward declaration or
an include is missing from one of the files.
Setting the target DEPENDENCIES might lead to confusing behaviour where
dependencies added to LIBADD are not propagated correctly. The automake
manual suggest using `EXTRA_%_DEPENDENCIES` when the goal is to augment
the automake-generated `%_DEPENDENCIES` instead.
Automake will correctly ignore any file included into a target source
when there is no suffix rule existing for turning those files into a
.$(OBJEXT) file.
Also, setting libvlccore.sym into a target _SOURCES automatically
configure it for distribution.
This is the proper way to export functions, regardless of our custom symbols
export file. This ensures the API definition in the headers match what happens
to the functions.
The libtool versionning is there to handle linkage compatibility during
runtime with older/more recent version of the libraries. On iOS and
tvOS, the dynamic libraries MUST be shipped in a framework. A framework
already provides its own way of handling versionning, and applications
cannot install global dynamic libraries (except maybe on jailbroken
devices) so cannot really use the libtool versionning features for
anything.
We cannot write suffix rules with dependencies that way. Fortunately,
there is only one usage of each of the 3 affected rules. This fixes the
GNU/make warning:
"warning: ignoring prerequisites on suffix rule definition"
There does not appear to be any real user. The "broadcast"
functionality can be reproduced more simply with the LibVLC media
player API. The "VoD" functionality does not make much sense outside of
the VLC executable process.
Within all the introduced static libraries, the module cannot be known
at compilation time. This moves the module name from a compilation
constant to a link time constant string symbol. That way, the same
compiled object within a static library can use a different and correct
module name depending on which plugin it is linked into.
The symbol is hidden so it does not leak between shared objects. For
non-plugins shared libraries (vlccore, vlc, vlc_pulse and
vlc_xcb_events) the module name must be defined manually, unless the
library does not use msg_* macros at all (vlc_vdpau).
This reverts commit 76118f5826.
It turns out this is actually an issue with libtool, cleaning the flags
when in link mode and removing the sanitizer flag.
It was fixed in libtool a5c6466528c060cc4660ad0319c00740db0e42ba
but there was no release since this fix.
Using sanitizer and no-undefined will cause linker errors on darwin due
to undefined symbols of the sanitizer.
This is adapted from a patch by Filip Roséen.
Otherwise, it gets executed with /bin/sh which on Solaris does not support the
$(...) construct. This causes 'gmake check' to fail. For example:
../src/check_headers: $(dirname ../src/check_headers): does not exist
Calling check_headers with $(SHELL) explicitly makes use of CONFIG_SHELL.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Thomas Guillem
Alexandre Janniaux
Steve Lhomme
Lyndon Brown
Rémi Denis-Courmont
Marvin Scholz
Hugo Beauzée-Luyssen
Rafaël Carré
Jean-Baptiste Kempf
KO Myung-Hun
Maciej Blizinski
Pierre Ynard
Rémi Denis-Courmont
Sam Hocevar