[vlc-devel] [RFC] Merging extras/tools & contribs

[Rémi Denis-Courmont]

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/