Le decadi 30 frimaire, an CCXXV, wm4 a écrit : > Also makes a lot of sense > from the point of view of people who use only some of the > sub-libraries, instead of the whole "framework". > > E.g. if you use libavcodec only, you don't want any hidden dependencies > on libavformat or any of the other libs.
If the libraries are merged, there is no "hidden" dependencies, there is only a libaveverything.so that contain codecs, demuxers, filters, crypto, etc. The application will only use a tiny part of it, but that is already true: a lot of applications only use decoders and do not care about encoders; a lot of applications only use video and do not care about video, etc. I do not think anybody considers libavvideodecoding, libavvideoencoding, libavaudiodecoding, libavaudioencoding? libavcommoncodecsvideodecoding / libavgamecodecsdecoding? Libraries are loaded on demand on supported OS anyway. And people who really care about the size of the blibrary / static binary can still build with almost everything disabled. > Personally I wouldn't mind if all the sub-libraries got merged into one > library (at linking stage). This is exactly what I would like. > Well, the idea is that if the split is done, it would actually make > sense to treat them as separate libraries. The result would be no worse > than with any other libraries. In theory. In practice, the ties between libraries are too strong to make it possible. You frequently see someone implementing a feature in lavu to use it in lavf. With separate projects, it requires rebuilding each project in turn. The project's build system is awesome; unlike all the c*p produced by autoconf / automake / autobreak, it sees all the dependencies, it does not rely on recursive make, and thus does the almost minimal amount of work every time and works in parallel flawlessly. With split projects, we lose that. Regards, -- Nicolas George _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
