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. 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. 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. For dynamic linking, there is an initial global phase of resolving symbols, that depends on the amount of symbols the application actually needs. Then the code is loaded on demand. Overall, "monterlibraries" are not the problem you think they are. Therefore, I suggest you revise your objections about them. > err^2 wouldn't we want to change that? There are plenty of good APIs that > could be used in the wild, but aren't because ffmpeg is a huge dependency > in any project. The reason people don't use our libraries for non-multimedia programs is not the size of the library. It is in part because of the reputation: they are multimedia libraries, there is no reason to use them for something else. And the other part is that our non-multimedia are pedestrian, inefficient and poorly designed. When we'll malloc() frames with thousands of pixels, we don't cringe at malloc()ing a six chars string. We have a terrible and ugly logging infrastructure that can cause unwanted noise. Etc. Until that changes, considerations about the size of the libraries are irrelevant when it comes to their adoption by non-multimedia projects. And remember, we are not a commercial project: we have no urge to create needs to gain market share. > 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. > 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. 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. 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. > Hard disagree on that one, but also quite off-topic, let's get back on > subtitles. This is an important discussion too. I changed the subject for people who want to track accurately. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
