On Thu, 16 Jul 2020 15:01:14 -0700, Darin Adler <da...@apple.com> wrote:
> > On Jul 16, 2020, at 2:28 PM, Adrian Perez de Castro <ape...@igalia.com> 
> > wrote:
> > 
> > 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.
> But it doesn’t.

Yes, because enabling/disabling features changes the set of source files to
build, which results in different source files being #included from each
unifier source compilation unit.

> Non-unified builds don’t make it possible to have arbitrary sets of features
> enabled at build time. We break that all the time and it’s only fixed when
> someone tests that arbitrary set of features. Headers are only a small part
> of that issue.

True, and that is why our message for the GTK and WPE ports is always that
we only support builds with the default build options, but of course anyone
is free to change them their mileage may vary.

In practice, we tend to keep things working in a best-effort basis for the
following few cases:

 - Disabling the Wayland or X11 support in the GTK port.
 - Disabling the WPE renderer in the GTK port.
 - Disabling multimedia support in the WPE port.

> I’d go as far as saying it’s not a project goal to always build with
> arbitrary sets of features enabled.
I agree. But even toggling the few features I mentioned above, or the target
architecture to something else than what the bots use, results in build
failures related to unified builds due to different sources being #included
in each unified compilation unit ¯\_(ツ)_/¯ 


Attachment: signature.asc
Description: PGP signature

webkit-dev mailing list

Reply via email to