On Fri, Mar 11, 2022 at 02:17:42PM +0200, Martin Storsjö wrote: > On Wed, 23 Feb 2022, Martin Storsjö wrote: > > > When updating the ffmpeg source, one quite often ends up in a situation > > where practically all of the codebase (or all of a library) gets rebuilt, > > due to updates to headers that are included in most files. > > > > In some cases, full rebuilds are warranted of course, but they could also > > be avoided in many cases - e.g. such as if the minor/micro version of > > a library has been bumped, or if a new component (codec, demuxer, filter > > etc) has been enabled (or removed if reconfiguring with an older source > > version). Very few source files are affected by exactly what the full > > library version is, or by the full list of enabled components. > > > > To avoid such rebuilds, I've got a proof of concept patchset that > > splits headers, so that most source files avoid including the bits that > > change often and that shouldn't affect how they are built. > > > > - The version.h headers are split into a separate version_major.h which > > contains only the major library version, and accompanying FF_API_* > > defines. The main library headers only include version_major.h, and > > files that need the exact version (e.g. LIB<name>_VERSION* or > > LIB<name>_IDENT) can include version.h explicitly. This is a minor > > break of the public API though, as definitions that used to be available > > no longer are. > > > > This works mostly fine for most libraries, but there's little point in > > splitting libavutil/version.h, because LIBAVUTIL_VERSION_INT is used > > in every source file that defines an AVClass. > > > > By splitting version.h, and update to the minor/micro version numbers > > of all libraries except avutil now would require recompiling 30 > > files instead of 1653 before. > > > > (This change also should lower the barrier to and reduce the risk of > > forgetting to bump the version numbers, which one otherwise often > > postpones while working on a patch, as it forces rebuilds.) > > > > - config.h is split into a separate config_components.h that includes the > > list of enabled/disabled components (corresponding to $ALL_COMPONENTS > > in configure). One could consider splitting up config.h even more, but > > that probably gives less benefit compared to the amount of churn. > > > > Surprisingly, a nontrivial number of source files do depend on the > > state of specific encoders/decoders/components, so quite a few files > > do end up requiring including config_components.h. (Also this change > > can possibly break compilation of source files that require external > > dependencies that I haven't tested.) > > > > In practice, this reduces the number of rebuilt source files from > > 1979 to 193, if there's a change to the list of enabled components > > but not to the rest of config.h. > > > > What do you think - is it worth the slight churn to avoid pointless > > rebuilds? > > Ping - I never got any feedback on the general concept of this patchset; is > either of the refactorings worthwhile?
I think its a good idea. Faster rebuilds & tests are always desirable thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
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".
