Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

2020-11-12 Thread Maciej Stachowiak via webkit-dev


> On Oct 17, 2020, at 10:00 AM, Sam Weinig  wrote:
> 
> Hi webkit-dev,
> 
> I’d like to propose, and gauge feedback on, reducing (with the goal of 
> ultimately removing) the use of Makefile based DerivedSources.make.
> 
> My understanding is that currently only the Xcode based ports still use 
> DerivedSources.make, as all the CMake based ones have moved derived source 
> generation to within CMake, so that should limit the scope of who this might 
> affect.
> 
> 
> Why do we use Makefiles today?
> 
> While I can’t recall the initial reasons for using Makefiles for derived 
> sources, over the years there have been a number of advantages to it that I 
> do know of. One clear advantage, that is no longer applicable, was code 
> sharing, as earlier in the project, at least the Apple Windows port did 
> utilize these Makefiles. Another was to work around some limitations in what 
> dependencies Xcode was able to track with build rules. It seems at least some 
> of the problems with build rules are no longer an issue, as we can now 
> specify inputs to build rules, but I don’t if other problems will still be 
> there, but for some prototyping I did, nothing yet has come up.

I think I might be responsible for this, and I think the reason was that at the 
time, Xcode could not properly handle derived source dependencies, and ended up 
either gratuitously rebuilding, or miscomputing by failing to regenerate a 
source, or failing to rebuild it when needed. It’s possible, maybe even likely 
Xcode handling of derived sources has improved since then. But the last attempt 
to do this via Xcode caused subtle broken build issues and/ir gratuitous 
rebuilding, so we’d have to validate that it doesn’t have these problems any 
more.

DerivedSources.make is also more human-editable without having to do so via the 
Xcode GUI.


> 
> 
> What would we move to?
> 
> As this only affects the Xcode based ports, we would move to distinct script 
> phases and build rules in the Xcode project.  
> 
> 
> Why make this change? What’s the benefit?
> 
> There are few reasons to consider this. One advantage is simplifying the 
> build system. Rather than two dependency systems (one for Xcode, one for the 
> Makefile) we reduce it down to one. And with additional knowledge of the 
> stages and dependencies, Xcode could potentially parallelize more phases. We 
> would would also save some time by avoiding invoking make in the first place. 
> 
> We also have a bit of an issue with make itself, as due to system 
> requirements, we are forever stuck with Make 3.81, which is coming up on 
> being 15 years old. More than once in the last year I have tried to 
> troubleshoot makefile issues, looking for resources on the web, only to be 
> stymied because the solutions I found required newer make.

One question in my mind is whether this would potentially lead to faster 
builds. If so, and the reliability problems from older Xcode’s are gone, then 
this would probably be a worthwhile change. But see below...

> 
> 
> What are the downsides?
> 
> One potential downside will be that it will be a bit harder for those without 
> Xcode to add new types of derived sources. I am not sure how much a real 
> problem in practice this will be, as editing project.pbxproj files is already 
> required for just adding new files, but I want to call it out anyway.
> 
> 
> What are your thoughts on this? Are there additional reasons we might want to 
> stick with or move away from Makefile based derived sources?

One additional though, I think we hope to move the Apple-maintained ports to 
CMake, so the value of changes to the Xcode-based build system may be limited. 
We think this could speed up both incremental and full builds significantly.

 - Maciej


> 
> Thanks,
> -Sam
> 
> ___
> 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


Re: [webkit-dev] Reminder: include everything that you use in implementation files

2020-11-12 Thread Yusuke Suzuki via webkit-dev
I think, without EWS / post-build bots using non-unified builds, this is 
difficult to achieve…

-Yusuke

> On Nov 12, 2020, at 4:16 AM, Adrian Perez de Castro via webkit-dev 
>  wrote:
> 
> Hello Peng,
> 
> On Wed, 11 Nov 2020 12:05:18 -0800 "Peng (WebKit) Liu via webkit-dev" 
>  wrote:
> 
>> Any way/option to turn off the unified build completely or partially in a
>> local build? That would be very helpful for a developer to locally verify
>> that header files are included correctly in a patch. Thanks!
> 
> You can use “build-webkit --no-unified-builds” to disable them; though I am
> unsure if this will work for the Mac/iOS ports… It surely works with the
> ports that use CMake (WPE, GTK, JSCOnly), and when using CMake you can also
> use “cmake -DENABLE_UNIFIED_BUILDS=OFF” if you would rather configure and
> build manually.
> 
> I hope this helps.
> 
> Cheers,
> —Adrián
> 
>> Best regards
>> Peng
>> 
>>> On Nov 6, 2020, at 11:21 AM, Brian Burg via webkit-dev 
>>>  wrote:
>>> 
>>> Hello folks,
>>> 
>>> I'd like to remind everyone to please include what you use in .cpp,  .mm, 
>>> and other files. When reviewing patches, please
>>> ensure that new mentions of classes, structs, etc. within an implementation 
>>> file have a corresponding header include. 
>>> All of our headers have #pragma once, so there is no downside to being more 
>>> explicit.
>>> 
>>> I've been noticing an uptick in the number of unified sources-related build 
>>> failures. I can't remember the last nontrivial patch
>>> I wrote that did *not* include unrelated build fixes. Typically these 
>>> failures aren't found until EWS results come back, reducing developer 
>>> velocity.
>>> And obviosuly it's super annoying to encounter completely unrelated build 
>>> failures that must be nonetheless addressed.
>>> 
>>> Let's all do our part so that hacking on WebKit remains delightful.
>>> 
>>> Thanks,
>>> 
>>> Brian Burg (he/they)
>>>  WebKit Developer Experience
> ___
> 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


Re: [webkit-dev] Reminder: include everything that you use in implementation files

2020-11-12 Thread Adrian Perez de Castro via webkit-dev
Hello Peng,

On Wed, 11 Nov 2020 12:05:18 -0800 "Peng (WebKit) Liu via webkit-dev" 
 wrote:
 
> Any way/option to turn off the unified build completely or partially in a
> local build? That would be very helpful for a developer to locally verify
> that header files are included correctly in a patch. Thanks!

You can use “build-webkit --no-unified-builds” to disable them; though I am
unsure if this will work for the Mac/iOS ports… It surely works with the
ports that use CMake (WPE, GTK, JSCOnly), and when using CMake you can also
use “cmake -DENABLE_UNIFIED_BUILDS=OFF” if you would rather configure and
build manually.

I hope this helps.

Cheers,
—Adrián
 
> Best regards
> Peng
> 
> > On Nov 6, 2020, at 11:21 AM, Brian Burg via webkit-dev 
> >  wrote:
> > 
> > Hello folks,
> > 
> > I'd like to remind everyone to please include what you use in .cpp,  .mm, 
> > and other files. When reviewing patches, please
> > ensure that new mentions of classes, structs, etc. within an implementation 
> > file have a corresponding header include. 
> > All of our headers have #pragma once, so there is no downside to being more 
> > explicit.
> > 
> > I've been noticing an uptick in the number of unified sources-related build 
> > failures. I can't remember the last nontrivial patch
> > I wrote that did *not* include unrelated build fixes. Typically these 
> > failures aren't found until EWS results come back, reducing developer 
> > velocity.
> > And obviosuly it's super annoying to encounter completely unrelated build 
> > failures that must be nonetheless addressed.
> > 
> > Let's all do our part so that hacking on WebKit remains delightful.
> > 
> > Thanks,
> > 
> > Brian Burg (he/they)
> >  WebKit Developer Experience


pgp3EqFjbVP0a.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Position on WebXr Lighting Estimation Module

2020-11-12 Thread Sergio Villar Senin via webkit-dev
O Mér, 11-11-2020 ás 11:21 -0800, Alex Cooper via webkit-dev escribiu:
> Hello Webkit,
> 
> I'd like to ask for WebKit's position on the WebXR Lighting
> Estimation Module. It's an extension of the WebXr Device API from the
> Immersive Web Community Group. The API allows web applications to
> request both the spherical harmonics representing ambient light as
> well as a reflection map. More details can be found in the explainer
> and specification draft.
> 
> Explainer: 
> https://github.com/immersive-web/lighting-estimation/blob/main/lighting-estimation-explainer.md
> Spec Draft: https://immersive-web.github.io/lighting-estimation/
> Chromestatus: https://www.chromestatus.com/features/5704707957850112
> 
> Could I get your position on this?

Not officially speaking on WebKit's name, but wanted to comment on
this. The API seems interesting and sane from the functional POV. I
just wanted to ask for the potential mitigations for the additional
fingerprinting opportunities it provides for attackers. For example, in
the case of the pose it's advised to use rounding,quantization and/or
fuzzing. Would that work for lightning estimation or would it cause
more harm than benefit (I'm thinking about the different VR sickness).

BR


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