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).
- 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
signature.asc
Description: PGP signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
