Clarifying feature flags

# Don.Olmstead at sony.com (5 days ago)

After I saw that CSS_PAINTINGAPI 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.

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 ENABLEWEBMETAL. 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.

Thanks Don

Contact us to advertise here
# Simon Fraser (5 days ago)

On Nov 5, 2018, at 6:01 PM, Don.Olmstead at sony.com wrote:

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

Agreed that this would be great to clean up. We’ve accrued a lot of junk in this area.

Simon

# Don.Olmstead at sony.com (3 days ago)

Any thoughts on what it would look like? If there are preferences we can work off of that.

From: webkit-dev <webkit-dev-bounces at lists.webkit.org> On Behalf Of Simon Fraser

Sent: Monday, November 5, 2018 11:41 AM To: Olmstead, Don <Don.Olmstead at sony.com>

Cc: webkit-dev at lists.webkit.org Subject: Re: [webkit-dev] Clarifying feature flags

On Nov 5, 2018, at 6:01 PM, Don.Olmstead at sony.com<mailto:Don.Olmstead at sony.com> wrote:

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

Agreed that this would be great to clean up. We’ve accrued a lot of junk in this area.

Simon

# Darin Adler (2 days ago)

A while ago Kentaro Hara did some IDL keyword cleanup.

One of the best things he did was to make a single file with a list of all the keywords. In that case he was able to set things up so that if the file was inaccurate the build would fail; not sure if that’s practical for the various feature flags, but it’s helpful to have a single place. Here’s a link to an interesting WebKit mailing list message about one of the steps in that <https://lists.webkit.org/pipermail/webkit-dev/2012-February/019501.html <https://lists.webkit.org/pipermail/webkit-dev/2012-February/019501.html>>.

I’d love us to find a similar way to “manage” and make it so someone can look over the entire list of feature flags and conditionals so we can spot problems easily.

— Darin

Want more features?

Request early access to our private beta of readable email premium.