[vlc-devel] [RFC] Merging extras/tools & contribs
Rémi Denis-Courmont
remi at remlab.net
Fri Feb 8 18:24:18 CET 2019
Le perjantaina 8. helmikuuta 2019, 12.26.53 EET Hugo Beauzée-Luyssen a écrit :
> Hi,
>
> 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.
> 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.
> 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.
But in any case, merging contribs with extras/tools as a whole sounds like a
major PITA.
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.
--
Реми Дёни-Курмон
http://www.remlab.net/
More information about the vlc-devel
mailing list