[Bf-committers] Policies about patches modifying third-parties libraries.

[Ray Molenkamp]

While i agree with "you should be able to build blender even with stock/system libraries"

I however do not think that the bar for "oh we'll just add it to /extern" should be as low as it appears to be. I'd be very much in favor of *NOT* adding a behemoth like USD to `/extern` (~75 megs, twice the size `/extern` currently, more than all the code in `/source` combined!) and ballooning an already high blender build time just to support a single IO format. 

Surely this can be worked out with upstream USD?

--Ray

On 2020-08-25 1:05 p.m., Bastien Montagne via Bf-committers wrote:
> Hi,
>
> Under build_files/build_environment/patches we have a bunch of small patches for the libraries we build using make deps. Most of them are about fixing builds for some platform or architecture, which is a bit annoying but acceptable imho.
>
> However, today I discovered that Blender cannot be built with vanilla USD library, at all. The patch used on this library adds some new function to its API, which (hack over hack) is not even declared in its headers, but in Blender code itself.
>
> I would very much like to propose to strictly forbid such dirty practices, which violate completely the very idea of libraries, especially on OSs like linux, where distributions try very hard to only use dynamically linked shared libraries.
>
> Any library that would need that kind of modifications should be put in extern/, and explicitly built as part of Blender itself. Or at the very least, we should explicitly maintain our own 'fork' of it, with requests to the main repo/maintainers to integrate our changes or otherwise propose a solution to the problem.
>
> But I do hope there are ways to avoid such ugly changes anyway?
>
> Cheers,
> Bastien
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers