From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 5DE4341109 for ; Wed, 16 Mar 2022 12:16:33 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9239268AEC2; Wed, 16 Mar 2022 14:16:30 +0200 (EET) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DAC5D680BBE for ; Wed, 16 Mar 2022 14:16:23 +0200 (EET) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 22GCGMwU018507-22GCGMwV018507 for ; Wed, 16 Mar 2022 14:16:22 +0200 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id BC6C0A1436 for ; Wed, 16 Mar 2022 14:16:22 +0200 (EET) Date: Wed, 16 Mar 2022 14:16:21 +0200 (EET) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: <20220314142326.GA2829255@pb2> Message-ID: <5bad83e9-34da-61b7-ae47-d3709f99a8d5@martin.st> References: <20220223142951.40366-1-martin@martin.st> <20220314142326.GA2829255@pb2> MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH 00/13] [RFC] Reduce unnecessary recompilation X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Mon, 14 Mar 2022, Michael Niedermayer wrote: > On Fri, Mar 11, 2022 at 02:17:42PM +0200, Martin Storsj=F6 wrote: >> On Wed, 23 Feb 2022, Martin Storsj=F6 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 rebuil= t, >>> due to updates to headers that are included in most files. >>> >>> In some cases, full rebuilds are warranted of course, but they could al= so >>> 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_VERSION* or >>> LIB_IDENT) can include version.h explicitly. This is a minor >>> break of the public API though, as definitions that used to be availab= le >>> 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 t= he >>> 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 Pushed now, thanks! // Martin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".