On Thu, Jan 21, 2016 at 11:41:19AM -0500, Vittorio Giovara wrote: > On Wed, Jan 20, 2016 at 3:44 AM, Diego Biurrun <[email protected]> wrote: > > On Tue, Jan 19, 2016 at 02:27:13PM -0500, Vittorio Giovara wrote: > >> On Tue, Jan 19, 2016 at 1:36 PM, Diego Biurrun <[email protected]> wrote: > >> > Leave these out or create proper fine-grained dependencies. Bloating > >> > the build for the other codecs is not acceptable. I have a very similar > >> > patch in a branch I need to revisit some day, waiting for me to address > >> > the same issues. > >> > >> ok what would be the best way to so though? a CELP target like the > >> current one and several other ones with less files compiled in? > > > > A solution so that no target gets bloated, i.e. all codecs have just > > the bare necessities compiled-in. Otherwise it's a size regression > > for certain builds. > > This is not a very helpful message: I proposed an alternative > solution, and one that does not take years to appears on the ML.
We have had this patch on the ml years ago, I wrote it. My patch had the same shortcoming as yours: It was not the right solution. You are not fixing a bug, you are refactoring. It's nice that you do, but I don't see how a small-scale refactoring like this one warrants any sort of regression. > At any rate the "size regression" you mention only happens if the dead > code elimination for that build is completely broken. What are you talking about? DCE happens at compile time, not during linking. Just try adding another object file to the list for libavcodec and watch the library's size increase. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
