those variables are usually changed simultaneously, qml would trigger an update
request for each variable updated and require detecting that the second call is
idempotent or making assumption regarding the call order to avoid the second
call.
this allows getting a single update point for the view.
previous implementation was only restoring subview by overriding the
defaultPage of the subview. this caused some issues:
- default was overridden, this is not desirable as the default was no logner
reliable from the POV of the subview
- the substate of the view wasn't restored, for instance if you opened the page
of a particular artist, it would restore on the home page of the artists.
If there's a pts, just respect it. Otherwise set the PTS to vlc_tick_now().
The documentation says it should be used like
> vlc -vv http://127.0.0.1:8081 --demux=stats --codec=stats --vout=stats
There's no reason force the "display" (logging) to render right away.
We may not want some of those logs to be dropped because they arrive late. But
we may also want to stat how frames are dropped, which is not possible with
this flag.
To show stats for all frames, even late ones use `--no-drop-late-frames`.
We don't have any system specific calls in our code. It seems the decklink_str_t
only needs special handling on macOS. It's a char* on Linux and Windows.
The bitcode flag was already added to CFLAGS, but was only used when
creating a static build of libvlc, which doesn't involve linkage. When
creating shared plugins, the dylibs must be linked with the
-fembed-bitcode flag to gather the bitcode from the different objects.
In particular, bitcode is mandatory on tvOS, so this is mandatory when
building dynamic plugins and/or libvlc for tvOS.
When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the
following happens:
- with LDFLAGS += -fembed-bitcode, the vanilla libtool version will
remove the -fembed-bitcode flag, being an unknown flag, so bitcode
won't actually be enabled, and final link steps might complain that
the dylibs (libvlccore.dylib for instance) doesn't actually have
bitcode embedded.
- once fixed (either by this patch or by using -Wl,-fembed-bitcode),
the plugins will be compiled with -module, which default to using
MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can
be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only
since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool
module support. However, MH_BUNDLE is not compatible with the bitcode
support from Clang.
Since we support MacOSX 10.11 as minimum, we can default to using
MH_DYLIB for plugins to have the bitcode support.
This new libtool patch add the explicit support for -fembed-bitcode in
libtool --mode=link flags, and change the flags used when using -module
in libtool to switch to dylibs.
Check that the linker features from Darwin ld64 for marking a symbol as
undefined (in the context of two-level namespace, it means that it can
be looked up in other namespaces) are usable. If they are not, the
static module bank is disabled since it depends on either static linkage
(which is obviously not affected by this option) or more generally the
ability to look up the static module bank symbol in a different linkage
unit/namespace.
In particular, they are currently not usable when enabling bitcode
through LDFLAGS+=" -fembed-bitcode" and compiling dynamically. On tvOS,
bitcode is mandatory, so supporting compiling with bitcode but without
the static module bank seems a rather good compromise given that it was
disabled anyway previously.
In static builds (the current shipping target for iOS and tvOS), the
static module bank stays enabled by the !HAVE_DYNAMIC_PLUGINS check.
Those frameworks only exist for MacOSX, so it was invalid to set them up
in the general case. Fortunately, it wasn't really used on iOS and tvOS
for the executables so it didn't have consequences.
On MacOSX, the targets needing this framework already link it so it is
not needed.
The SSL*ALPNProtocols were introduced in recent OS version, and dynamic
lookup (using ld64 option -Wl,-U) was used to make it work during
link-time and potentially not have the function available.
However, -Wl,-U is not compatible with bitcode support, whereas
availability targeting is, and availability targeting provides more
information about when it's not supported.
MacOSX 10.13.4 is the minimal version target in cURL too. The
SSL*ALPNProtocols functions are documented as supported since 10.13 but
they were not included in the initial 10.13 releases.
This is not supported with -bundle_bitcode, and was only supposed to be
used on 32bit anyway. It seems to be only a legacy flag now.
From ld64 man:
-read_only_relocs treatment
Enables the use of relocations which will cause dyld to
modify (copy-on-write) read-only pages. The compiler
will normally never generate such code.
Mehdi Sabwat
Pierre Lamot
Francois Cartegnie
Steve Lhomme
Hugo Beauzée-Luyssen
Benjamin Arnaud
Alexandre Janniaux
Rémi Denis-Courmont