[vlc-devel] [RFC] Merging extras/tools & contribs
Steve Lhomme
robux4 at ycbcr.xyz
Mon Feb 11 07:48:58 CET 2019
On 09/02/2019 10:53, Rémi Denis-Courmont wrote:
> Le lauantaina 9. helmikuuta 2019, 9.48.32 EET Steve Lhomme a écrit :
>>> In principles, you *can* compile native code within contribs. This is what
>>> the luac target does due to hysterical raisins. There may be regressions,
>>> if some cross-compilation variable values are leaked by an export or
>>> such. Normally, they should only be set with HOSTVARS or HOSTVARS_PIC, as
>>> this advises (for>
>>> xFLAGS variables):
>>> | # Do not export those! Use HOSTVARS.
>>>
>>> Regardless, building native executables in contribs is rather nasty. The
>>> resulting (pre-built) contrib would depend on a specific build
>>> environment,
>>> which it really should not.
>> I thought prebuilt was dead, at least for license reasons.
> Uh, please clarify. I don't understand how licensing could affect prebuilt VLC
> contribs any more or less than built VLC releases.
I can't find the thread in my emails so maybe it was on IRC or IRL. But
the general idea was that if we build all contribs, even GPL ones, some
people might end up building/distributing VLC with these without
realizing it.
Aside from that, unless the contribs are built with the same toolchain,
especially regarding C++, there's a high chance the prebuilt package
will not work for most people. Let alone the protoc compatibility gamble.
prebuilt saved my life so many times in the past when the contribs
wouldn't build properly with msys2+mingw64 but now all this is solved.
So at least on Windows people should not use that anymore (for the
reasons stated above) and I don't know if contribs make sense elsewhere,
maybe macOS ?
More information about the vlc-devel
mailing list