[webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Chris Dumez]

> On Aug 29, 2017, at 9:24 AM, Keith Miller <keith_miller at apple.com> wrote:
> 
>> * We could not use any namespaces and just fix name clashes as they arise, but only if we have some more predictable way to determine which files will be built together regardless of port or build configuration. Say files in small directories all get built together, while files in large directories get built together if their filenames start with the same letter. That might be too confusing, but a scheme like that would make it possible for us to ensure we don't have name clashes regardless of port configuration, while avoiding the need to add namespaces all over the place.
> 
> I had considered something like this. Ultimately, I decided the FILENAME solution was better because it lets us use descriptive names without having to unique the name. When new cpp files are added to the project, if we don’t use a namespace solution new errors in totally unrelated files may appear due to reordering of the unified source lists. For new developers, errors exclusively in .cpp files they didn’t touch would be particularly frustrating and confusing. e.g. They add Foo.cpp which causes Bar.cpp and Baz.cpp to get bundled together causing a redefinition error in Bar/Baz.cpp. While, new developers might also be annoyed with the FILENAME solution, it’s a pretty simple rule to follow and it doesn’t lead to the same surprises. 


Keep in mind that if you do this, you may not get a build error and still run into trouble. If several static functions end up having the same name but different parameters, your code may build but may end up crashing or with different behavior because we end up calling a different overload. This would seem very risky for a big project such as WebKit.

--
 Chris Dumez

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20170829/8a200ab5/attachment.html>