I worry about adopting unity build because while it makes clean builds faster, it also slows down incremental builds. As a developer, I rarely do clean builds, I mostly do incremental builds so this would likely make my experience worse? Unity builds also require a lot of code churn to resolve naming conflicts and the resulting code does not look as nice.
Finally, the statement that the slow down of incremental build is acceptable because we spend most of our time resolving dependencies seems to assume we keep using make. Using Ninja would speed up incremental builds a lot by not re-resolving dependencies so much. -- Chris Dumez > On Aug 29, 2017, at 9:05 AM, Darin Adler <da...@apple.com> wrote: > >> On Aug 28, 2017, at 8:34 PM, Ryosuke Niwa <rn...@webkit.org >> <mailto:rn...@webkit.org>> wrote: >> >>> Wherever possible, we are going to want to convert file-static functions >>> into private C++ class member functions. >> >> I don't think we should make this change. It would mean that whenever >> the function signature changes, we'd have to modify the header file, >> which in turn triggers rebuild of every cpp file which includes that >> header file. > > > That was my first thought as well. In fact, I typically ask people to do the > opposite: Whenever a function does not require access to private members, > convert from a member function that has to be in the header file to a > function that is private to the source file. > > More recently I have started doing something different for the many functions > that only have to be used on one place; I use lambdas to create nested > functions. This has a couple nice properties: The lambda shares access to > private members and anything else that the surrounding function has access > to. We have the option of capturing rather than passing arguments, which can > be clearer in some cases. It’s not quite as good as a separate function for > visual separation; the lambda is often mashed together with the rest of the > surrounding function. > > — Darin > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
