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 ¯\_(ツ)_/¯ Cheers, —Adrián
Description: PGP signature
_______________________________________________ webkit-dev mailing list firstname.lastname@example.org https://lists.webkit.org/mailman/listinfo/webkit-dev