[FFmpeg-devel] Discussion of all-inclusive full stack builds

Tim Jones tolistim at gmail.com
Mon May 13 04:18:02 EEST 2019


On May 12, 2019, at 4:14 PM, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> On Sun, May 12, 2019 at 12:07:42PM -0700, Tim Jones wrote:
>> On May 12, 2019, at 11:54 AM, Nicolas George <george at nsup.org> wrote:
>>> 
>>> Tim Jones (12019-05-12):
>>> 
>>>> --disable-all-proprietary/--enable-all-proprietary
>>> 
>>> As for this one, on the other hand, there will be opposition: we do not
>>> want encourage users to use proprietary software. In fact, there is
>>> currently a discussion to refuse including new proprietary components,
>>> and possibly getting rid of the ones we included without thinking.
>> 
>> I don't want to start a thread war here, but isn't the purpose of any toolchain to allow for the support of a given task?  If there isn't a FOSS option and an easily obtained proprietary solution exists, why block it?
>> 
>> This is one of the things I hear from new Linux users when running into the FOSS vs. proprietary brick walls - they just want a platform that works.  The FUD that is continuously promoted concerning adding non-FOSS components - Nvidia drivers, ATTO drivers, HighPoint drivers, custom audio device drivers - has caused a number of potentially large Linux opportunities to move to Windows.
>> 
>> I've long been a proponent of FOSS where it is apropos, but I also understand Heinlein's TNSTAAFL :) .
> 
> Well, which is a fairly good argument to enable proprietary components
> only in specific cases.

Which is why I asked in my original question if an optional config setting had been discussed previously.  

If autodetection is an issue "in general", then the option should be to --disable-external, or my --disable-all-proprietary, by default.  This flag could then be reversed by the builder to include any external/proprietary libraries found with the understanding that if something is broken, the builder must revert to the --disable-external config and rebuild before attempting to report a bug or other problem.  Then it would be up to the builder to determine which of their external features/libraries were causing the build failure or problem.

We do this with a few sensor-specific library collections I work with on the Arduino and Raspberry Pi platforms.  The user builds with the defaults - if it works, add their custom sensor packages.  If it breaks, report that to the creator of your custom sensor module package instead of the upstream team. Works perfectly in each case and the primary team doesn't have to worry about that new hydrology sensor that has added salinity levels to the mix (which we don't even know about).

--
Tim




More information about the ffmpeg-devel mailing list