I forgot to mention one tidbit... On Fri, 17 Jul 2020 00:28:53 +0300, Adrian Perez de Castro <ape...@igalia.com> wrote: > Hello everybody, > > On Thu, 16 Jul 2020 12:57:01 -0700, Darin Adler <da...@apple.com> wrote: > > > On Jul 16, 2020, at 12:54 PM, Kirsling, Ross <ross.kirsl...@sony.com> > > > wrote: > > > > > > Non-unified build fixes are done to support *all* platforms, because > > > sudden unification shifts can happen anywhere. > > > > I’m not sure that benefit is worth the additional code churn. I understand > > that it’s frustrating to run into a problem when unification shifts, say > > when you are adding a source file. I believe we have made changes to > > unification since the earliest version that reduce how often unification > > shifts. > > While this is true, shifts still happen easily when changing anything in the > build configuration that affects the list of source files to build. The cases > in which I have seen this happening when using the CMake based ports are: > > * The target architecture is not one of the few tested by the bots. > > - For the GTK and WPE ports this means that a build for anything else > than x86_64 is susceptible to break easily. > > - Note that JSCOnly builds on ARM, MIPS, and i386 are actively tested by > EWS bots, so the JSC build is less likely to. > > * The features enabled at build time are changed from what the EWS bots test. > > - Happens when the build configuration (via CMake) changes the defaults. > For example one can build the GTK port with support for Wayland enabled > and X11 disabled (the default is both enabled). Or one can build WPE > with > all media support disabled (which completely avoids needing GStreamer, > making the disk footprint considerably smaller: this is sometimes done > when targeting embedded devices).
As a matter of fact: lately I have been trying to make sure that non-unified builds are working *right before* making source tarball releases for the WPE port, and the reports of build failures due to unification issues has been zero ever since. Also, some packagers used to carry assorted downstream patches for build issues related to unification build which have not been needed anymore. The case I know better is Buildroot [1]: when I started maintaining its package for the GTK port in preparation to submit the WPE package one of the tasks I did was precisely avoid downstream patches, by applying the fixes to WebKit itself—and *that* was when I learnt that making non-unified builds work was a good thing. > - Bots test with experimental features enabled, but the default setting when > building from source tarballs has those disabled at build time. This is > less likely to result in a broken build than manually toggling features, > it can happen. > > It is not feasible to test unified builds for all the possible combinations of > target architectures and set of features enabled at build time (there is a > combinatorial explosion of configurations). Keeping non-unified builds in a > working state guarantees that regular unified builds will keep working no > matter what the build configuration is. > > Another side effect of keeping non-unified builds usable is that it is > possible to build WebKit on machines with less RAM (granted: only release > builds without any debugging information), which sometimes has enabled people > who don't have access to beefier machines to get WebKit built and even work > on patches. While this has not been very common, I think it's a commendable > goal to allow people without access to beefy computers to contribute to > WebKit :) > > Best regards, > —Adrián --- [1] https://buildroot.org/
signature.asc
Description: PGP signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
