[FFmpeg-devel] Splitting or merging libraries (was: Status and Plans for Subtitle Filters)

[Vittorio Giovara]

On Sun, Mar 1, 2020 at 6:54 AM Nicolas George <george at nsup.org> wrote:

> Vittorio Giovara (12020-02-28):
> > err a monsterlibrary is a monsterlibrary regardless of how it is linked,
> > and it's good that you mention static linking since that would be one of
> > the best reason to keep library separated
>
> You seem to have some basic misconceptions about how linking works,
> which result in completely incorrect conclusions. Let me elaborate.
>

I'd appreciate if we could keep the conversation cordial, rather than
throwing assumptions on people.
This is a pretty hard start, and I will not continue on this thread if this
is the tone going forward.

First, if you take a monsterlibrary and configure it with
> --disable-everything --enable-what-you-need, you get a tiny library.
> Therefore, the maximum size of the library is not an issue for the
> people who ship their own.
>

First of all the "size" of any code is pretty much the least important
aspect of development, unless we're talking the embedded world or assembly
optimizations.
That does not mean one should be allowed to make the code purposely larger
for no gain: so far I haven't heard any good motive for merging the
libraries together, while the ones for splitting them even more are pretty
evident.


> For static linking, it's even simpler. Static linking does not copy the
> whole library, the linker only picks the object files it needs based on
> the symbols the application uses. You can have a monsterlibrary; you can
> have ten extra useless monsterlibraries, it will change nothing: the
> resulting binary will contain exactly the code it needs.
>

In a perfect world, sure, but that is not the case. To my knowledge most
compilers do not perform such pervasive code elimination, unless when
configured with extremely obscure parameters. This presentation seems to
illustrate the problem well
https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf


> > There are plenty of example in which imposing constraints on the code or
> > language forces developers to write better code.
>
> And there are plenty of examples where arbitrary constraints lead to
> worse code.
>

I feel like we're starting to go in the agree to disagree section :)


> > For example splitting the libraries would make sure that a private header
> > does not "leak" to a dependent library, like in a patch that was
> published
> > a few days ago.
>
> But the "leak" is only a problem because the libraries are separate.
>

No, it was a problem from a design point of view, there are different
libraries dedicated to different things, merging everything together serves
no purpose, while separating them a bit more, would introduce new
functionality and features in the project.


> The fact is, we develop these libraries as a whole. Codecs, muxers and
> filters are often written by the same person and use the same tables and
> small utility functions. These are functions that are too specific and
> anecdotal to be public functions. We can update them easily, including
> their prototype, because they are used only at two or three places in
> code we know.
>

This is very very anecdotal. Besides, you don't know how a library will be
used by the application, I believe you'd be surprised.


> If we stopped caring about separate libraries, we would just name them
> ff_someobscurecodec_get_random_info() and call them whenever necessary.
> But because people insist on split libraries, we have to jump hoops and
> waste effort.
>

Well by that reasoning, why isn't everything compiled in-kernel? After all
we're just wasting precious user memory when everything could run from
kernel space right?
Maybe encoding and decoding could go 1% faster!!!

Whether you like it or not, there is value in designing separate tools and
implementing separate tools and libraries for different use cases: even
though the ffmpeg suite of library is closed together because they pertain
the same subject (multimedia) it makes a lot of sense to keep them separate
and try to identify portions of code that could work well enough in a
library separated from the rest.
-- 
Vittorio