[webkit-dev] What's the rationale for not including config.h in any header files?

[Keith Miller]

I’ve done some experiments with automagically building the unified source files. I have some data that I’ll share with the rest of WebKit when I have more information. But as a quick note, since my current approach to unified sources has the build system decide which cpp files to bundle together, the number of cpp files in the same translation unit will probably be if you think you will likely be doing a lot of incremental builds.

I agree that there are definitely a number of downsides to unified sources. Ultimately, my primary goal is to make the developer experience as smooth as possible, I’m less concerned with production build times. Although, I would like to improve production build times also.

Cheers,
Keith

> On Aug 1, 2017, at 3:48 PM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
> 
> On Tue, Aug 1, 2017 at 11:33 PM, Keith Miller <keith_miller at apple.com> wrote:
>> P.S. There is also a reasonable chance that we will do some form of unified sources (compiling multiple cpp files at the same time). In that case we don’t need to change our config.h rules.
> 
> Do you have experience with unified source builds on macOS? We basically never do these on Linux, but it's of course possible. These builds are typically great for production but terrible for development, since everything needs to be recompiled when any file is changed. Also, using static to mark functions as file-private no longer works. This is sure to cause headache. But the benefits may be worthwhile.
> 
> Some good description:
> 
> http://mesonbuild.com/Unity-builds.html <http://mesonbuild.com/Unity-builds.html>
> 
> Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20170801/1cf2a279/attachment.html>