[FFmpeg-devel] [PATCH 00/13] [RFC] Reduce unnecessary recompilation
Michael Niedermayer
michael at niedermayer.cc
Mon Mar 14 16:23:26 EET 2022
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220314/b39c717c/attachment.sig>
More information about the ffmpeg-devel
mailing list