> 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
