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

[Hugo Beauzée-Luyssen]

On Mon, Feb 11, 2019, at 9:10 AM, Rémi Denis-Courmont wrote:
> Hi,
> 
> The thing is, the Win32Compile wiki page still advises using prebuilt 
> contribs. I don't think GPL is a problem on Windows desktop. That being 
> the case, I don't thini we can break prebuilt contribs...
> 
> (It might be a problem for proprietary LibVLC apps, but regardless of 
> prebuilt contribs.)
> 
> Le 11 février 2019 08:48:58 GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
> >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 ?

I must say I didn't think about the prebuilt contribs... Due to the reasons Steve mentioned earlier, I'm wondering if prebuilt is something we should advertise or advise to use, at least when cross compiling for Windows.
 It was painful enough to have a match between c++ ABI, exception flavor, and threading flavor when we were only using GCC, but now that we start using llvm, it's even more complicated.

As Rémi mentioned, the lack of proper dependencies is a huge pain point in extras/tools, which makes me want to get rid of it, but propagating the auto** dependencies to all packages isn't something I though about either. That being said, it's tedious but not complicated to add those.

Regarding storage, I don't think we can avoid having 2 extraction folders anyway, I'm not entirely sure Qt will handle a single source folder with 2 targets, and AFAICS lua doesn't support out of sources build. What I'd like to avoid is to download the tarballs twice though.

Regards,

-- 
  Hugo Beauzée-Luyssen
  hugo at beauzee.fr