On Mon, Aug 28, 2017 at 8:10 PM, Michael Catanzaro
<mcatanz...@igalia.com> wrote:
> On Mon, Aug 28, 2017 at 7:37 PM, Keith Miller <keith_mil...@apple.com>
> wrote:
>>
>> Given that most of the build time in incremental builds is scanning
>> dependencies, this change is probably only barely noticeable.
>
>
> What, with CMake? That's true of the make backend, but definitely not the
> ninja backend. You should pass -GNinja to get the ninja generator. I thought
> the build-webkit script already did this by default.
>
>> Bundling happens as part of the CMake configuration process, in the CMake
>> build.
>
>
> Do you have a patch or branch somewhere we could look at? This is very
> exciting!
>
>> namespace FILENAME {
>>         static int myVariable { 0 };
>>         static int myFunction() { return myVariable; }
>> }
>
>
> I'm afraid you might be underestimating how much pain this would be. We use
> file-static functions all over the place, scattered across source files. We
> can't reasonably add namespace guards around individual functions scattered
> all throughout files, so we're going to need to move them all to one place,
> in the files, which will seriously hurt readability. Regardless, we will
> need a lot of forward declarations to make this workable. (At least those
> can all go in one place.)
>
> I'm not saying this is a bad idea. I think we should try it. We should be
> willing to put up with some annoyance in order to get faster builds. But I
> suspect converting the WebCore and WebKit layers is going to be a lot harder
> than JSC.
>
> 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.

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

Reply via email to