[vlc-devel] [RFC] Merging extras/tools & contribs
robux4 at ycbcr.xyz
Sat Feb 9 08:48:32 CET 2019
On 08/02/2019 18:24, Rémi Denis-Courmont wrote:
> Le perjantaina 8. helmikuuta 2019, 12.26.53 EET Hugo Beauzée-Luyssen a écrit :
>> A few words of context: we (well, Pierre) started looking into using
>> qmlcachegen to pre-compile our QML files. It works nicely on linux, but
>> things get trickier when cross compiling. The tool is in a separate Qt
>> package (qtdeclarative), and requires Qt to be built (or at least a minimal
>> subset of it, ie. QtBootstrap) Said tool will therefor look for installed
>> Qt bits in the contribs $prefix, which also contains (or is likely to
>> contain) an install of winpthreads, and therefor a pthread.h. The fun
>> begins when the tool tries to use pthread.h assuming it's a regular linux
>> pthread implementation, but ends up using the winpthread's one.
> 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.
I suppose the native and target builds would be separated in the contrib
and be called independently. So one could be prebuilt and not the other,
and build one and not the other. So it's not really an issue.
>> TL;DR: Mixing native build & cross compilation in the same folders is not a
>> good idea and will cause pain, if it hasn't already (hint: it already has)
> As for as contribs are concerned, that is not supposed to happen. Native
> targets are (supposed to be) installed in contribs/$type and with any
> applicable cross-compilation prefix, while cross-compiled targets are installed
> in contribs/$triplet/$type.
> Compare contribs/bin/i686-w64-mingw32-luac
> and contribs/i686-w64-mingw32/bin/luac.exe .
>> There are various solutions to the specific problem.
> Well actually there are not that many. You can either do it from contribs like
> Lua already does, but that hurts pre-built contribs. Or you can do it in
> extras/tools but you need to download twice.
From the same source it should be possible to build in separate
directories for native and target if needed.
>> IMO, the best option is to support building native tools from the contribs.
>> The exact plan is not clearly defined yet, but I'd like to have your
>> opinion first, before starting to tackle this.
> Well IMO, it is the other way. Storage is cheap.
Having cleaned 150GB of build folders the other day, I tend to disagree.
It also makes the building process slower and use more power (think of
> But in any case, merging contribs with extras/tools as a whole sounds like a
> major PITA.
Yes, it's going to be a bit of work. In the long term I think it's a
We already got tons of problems with Lua, then with protobuf and now
> First, you would have to essentially rewrite tools, as they still use the old
> contrib half-assed Makefiles without proper dependency propagation (literally
> been there done that).
> And then you would have to explicitly add an enormous number of currently
> implicitly dependencies to existing contrib targets: tar, autoconf, etc.
> Реми Дёни-Курмон
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel