29.08.2017, 23:54, "Alicia Boya García" <ab...@igalia.com>: > I'm all for stable bundle .cpp files. Automatic generation can be nice > for the first time... and once in while we can try to modify the bundles > to try to make the build even faster, but really most of the time bundle > contents should not change unless new files are added and everybody > should get the same bundles. > > If we're going to end up with some name collisions, we'd rather do so > that every build of the same source tree gets collisions or no build > gets them. > > The description of these .cpp bundles should become a project artifact, > shared and versioned in the repository and treated carefully as such.
This is already the case for *AllInOne.cpp files of WebCore, which are enabled by -DENABLE_ALLINONE_BUILD=ON option (--allinone-build in build-webkit). > > Also, in my earlier message about unified builds I explained how the > distribution of the files within the bundles also affects the number of > bundles that are rebuilt in response to changes in the source code. I > also proposed that grouping together files implementing the same > features could be a good start point to minimize the impact of this issue. > > On other note, I don't think namespacing static functions and variables > as originally proposed is the way to go. > > The refactor would be ridiculously huge. Running `rg -w '^static' -tcpp > --no-filename --no-heading |wc -l` in my local repository yields 16797 > instances of static functions and variables, only taking into account > those where the word static is at the beginning of the line without any > spaces before, which is a common case but not a requirement in C++. Note > though that this regex excludes static class members as long as code is > properly formatted (they would be indented); these are not included as > they would not need any changes. > > static functions and variables in WebKit are used for hidden > implementation details, which tend to very very specific and therefore > receive long specific names with relatively little risk of collisions. > > Furthermore, collisions won't go unnoticed as in every case they will > trigger a compilation error of the likes of 'redefinition of ‘int a’'. > In this case the compiler will also show the inclusion stack mentioning > the bundle file and the conflicting definition. The programmer will > notice that both are static members in .cpp files, so the only way that > error can arise is because they had a name collision due to unified > source builds. > > We'd probably be better off handling the few collisions on a one by one > basis, renaming the symbols or excluding the worst offenders from > unified builds rather than plain out forbidding static declarations. > > -- Alicia > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev -- Regards, Konstantin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
