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

[Rémi Denis-Courmont]

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.

As far as I am aware, we have carefully avoided adding any nonredistributable 
stuff in contribs. And if nondistributable code is ever added to contribs 
anyway, it really should never be enabled automatically - so it would not show 
up accidentally in prebuilt contribs or built releases.

As for copyleft code, our obligation to distribute source code is the same 
whether it stems from prebuilt contribs or from continuous/nightly builds. 
Contribs has the fetch-all target expressly for that purpose.

> > 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.

Yes, of course. That is how Lua and LuaC are handled already. But that breaks 
the build system independent property of prebuilt contribs.

> >> 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
> the planet!).

Contribs are carefully designed to avoid useless downloads.

> > 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
> good thing.
> 
> We already got tons of problems with Lua, then with protobuf and now
> with Qt.

I don't really see how Lua is any different from any other compiled code that 
we have. If anything, Lua is much easier than C/C++, because it only depends 
on the scalar representation, not the instruction set.

Protobuf still causes a lot of problems due to version incompatibility, not 
cross-compilation. It is just as bad for native builds as cross-compiled ones. 
In fact, it might be worse for native, due to conflicts between system native 
protobuf and contribs native protobuf.

-- 
レミ・デニ-クールモン
http://www.remlab.net/