[webkit-dev] Unified sources have broken our #include hygiene
fwang at igalia.com
Thu Sep 13 03:49:07 PDT 2018
I've recently found two non-trivial issues with unified builds. They are
not missing #include but instead conflicts between C++ files:
- Two C++ files including the same header but with a #define directive
set to different values .
- One C++ file including a header with implicit template instantiation
in an inline function before an explicit template specialization in a
second C++ file. 
I guess there could be more examples like this (e.g. functions with
conflicting names in two C++ files...). Should we allow to prevent some
files to be included in unified build? This is possible in Mozilla's
build system for example .
Or should we always try to re-write the code to fix the conflicts
between files? This might go against our usual practice: For example the
current solution I have for  is to move the function from the header
to its implementation C++ file, losing potential performance benefit of
On 02/09/2018 02:14, Simon Fraser wrote:
> Unified sources allow you to get away without #including all the files you need in a .cpp file, because some earlier file in the group has probably already included them for you.
> This means that when you add a new file to the build, and the unified sources get shuffled around, you end up with a long list of build breakages, some platform-specific, that you can only fix by repeating EWS trials. Here's an example: https://bugs.webkit.org/show_bug.cgi?id=189223. That patch added on new file in Source/WebCore/rendering, which required unrelated #include changes in at least:
> How can we solve this? Should we have an EWS that builds non-unified? Can we somehow have the style checker do #include enforcement?
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
Frédéric Wang - frederic-wang.fr
More information about the webkit-dev