> There is no such thing as "not maintaining the non-unified build"; there 
> never has been. We have covered that this is an *inherent* problem in a 
> unified build mechanism and that this would be an issue even if Mac were the 
> only platform.

It appears to me that we’re lacking the clarify in defining what problem(s) 
we’re trying to solve here. As far as I can tell, fixing non-unified builds is 
a potential solution to two problems:
Adding a new cpp file to Sources.txt causes random other file to trigger a 
compiler error because the set of cpp files unified together have changed / 
shuffled across.
Build failure may occur in an exotic port or configuration which unify a 
different set of cpp files than the supported configurations.

(1) might be a problem worth solving but there are multiple solutions to this 
problem. For example, we could stop lexicologically sorting cpp files in 
Sources.txt, and always append new cpp files at the end of each directory 
instead. This will avoid shuffling cpp files that are unified together when 
adding new cpp files. Someone who feels like it could come in & sort files 
occasionally, or maybe we should just forget about this entirely and let the 
chaos ensue. Either solution seems less costly than forcing every contributor 
to maintain non-unified builds functional.

While I’m sympathetic to the view that (2) is a problem or that it would be 
nice for the WebKit project to address the concerns of such exotic 
configurations or ports, I just don’t see how this differs from all other build 
failures that occur from WebKit code changes such as refactoring of platform 
abstraction. I grant that build failures which are effect of cpp files getting 
unified differently across different ports and configurations might be tricky 
to diagnose.

Even if we were to agree that (2) is a problem worth addressing, again, there 
are multiple solutions to this problem. We could, for example, stabilize cpp 
files that are unified across configurations / ports so that if a set of cpp 
files get unified under one configuration, they will always get unified in all 
other configurations. In practice, this might mean moving every platform 
specific file into a sub directory and unifying them separately for example.

- R. Niwa

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to