login bonus link maxbet 2019_Welfare offer free 5 sports bet no deposit required_login bonus w88 live chat

free online bettingMon, 05 Nov 2018 09:03:27 -0800

Hi WebKittens,

After I saw that CSS_PAINTING_API wasn't exposed in CMake I took a stab at 
looking into the different ENABLE_ flags inside WebKit's source to try and get 
what's exposed on the XCode side synced. I ended up searching through the 
source code and found around 200 different ENABLE_ flags.

https://bug-191167-attachments.webkit.org/attachment.cgi?id=353663 has the 
listing. It was just generated by blindly greping the source code with Python.

I'm wondering if there's any way to get a better taxonomy on these things. I 
know there are other macros like HAVE and USE which some of these options might 
better fit into.

Some flags seem to be around internal debugging like ENABLE_YARR_JIT_DEBUG and 
a bunch of stuff looks applicable to JSC debugging. So as an example maybe 
DEBUGGING(YARR_JIT) might be a better way to flag things. Then maybe 
build-webkit can have some flags which enable different debugging scenarios.

Some flags are tied to ports. Only Apple ports are going to have support for 
ENABLE_APPLE_PAY and ENABLE_WEBMETAL. Maybe those should be under HAVE_ or USE_ 
or perhaps there's a way to better convey that its definitely port specific. 
This is probably dependent on whether it's something you'd want to toggle.

Then there are features that are in various states.

Some for sure are complete but you may want to turn off or on like WebGL or 
video support based on your platform. For those there should definitely be an 
ENABLE or maybe FEATURE might be a better way to designate it when A port has 
shipped an implementation.

Some are not port specific and can be turned on when complete, 
YARR_JIT_BACKREFERENCES, sticks out that it is likely going to be removed once 
the tests all pass. Maybe DEVELOP or EXPERIMENTAL would be a better 
designation. If it requires a port to do some work to enable it then perhaps 
that information can be passed along as well.

There's also some stale code like enabling web components in the perl and stuff 
like ENABLE_ACCESSIBILITY in the CMake that are just hanging out without 
actually doing anything.

Anyways those are just some thoughts on how we might be able to get things a 
bit more under control and clue developers in a bit more on what things are so 
they can utilize it all.

As a side effect perhaps we can also get more tooling around this so we can 
also keep the XCode and CMake bits in sync. I was messing around with some code 
generation in python around it and I'd be happy to throw those up as patches if 
there's interest.

I'm really interested in other people's thoughts on this.


webkit-dev mailing list

Reply via email to