[webkit-dev] Re: [webkit-changes] [29033] trunk
Darin Adler wrote: The #if at include sites approach is better for people who want to omit the code entirely for features that are not enabled. You don't even need the headers in your patch. But the #if in headers approach is probably lower maintenance, since there are usually multiple includes for each header. I have a slight preference for Jan's convention, B: (A) #include "DatabaseTracker.h" (B) #if ENABLE(DATABASE) #include "DatabaseTracker.h" #endif * B avoids triggering rebuilds every time DatabaseTracker.h is changed, saving time for developers who track TOT. * B cuts down stat() calls at build time. Makes a difference when building on Windows where this operation is slow. * A doesn't make it clear that DATABASE is optional so it's more likely to lead to build breakage by new developers who may be unaware the these features can be disabled. B makes it very clear that database code needs to be guarded. So while there's precedent for both A and B in WebCore I think we've made a improvement here. Still no strong objections if you want to back this out. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re: #if style
On Jan 1, 2008, at 12:19 AM, Alp Toker wrote: I have a slight preference for Jan's convention, B: Sure, those arguments make sense; faster builds for people who have a feature disabled. * A doesn't make it clear that DATABASE is optional so it's more likely to lead to build breakage by new developers who may be unaware the these features can be disabled. B makes it very clear that database code needs to be guarded. I am not sure I'm convinced on this point. I think that the #if ENABLED in the header is pretty prominent, perhaps even more prominent than the one in the include list. It's useful to know when looking at a header that all this code is conditional. Still no strong objections if you want to back this out. I want the project to be consistent. I'm not passionately in favor of one approach over the other, but I dislike the mix of the two approaches. I'd love to see a patch that moves us all the way in either one direction or the other. This is not an urgent matter. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Enabling all SVG features...
Devs: Just wondering if there's a way (or there could be a way) for someone to enable all of the experimental SVG features with a single flag, rather than having to enable them all individually. A setting that would stick around, like the Debug or Release build settings, would be great. Jon Shier ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling all SVG features...
While it doesn't stick around the --svg-experimental flag should do the trick --Oliver On Jan 1, 2008, at 12:36 PM, Jon Shier wrote: Devs: Just wondering if there's a way (or there could be a way) for someone to enable all of the experimental SVG features with a single flag, rather than having to enable them all individually. A setting that would stick around, like the Debug or Release build settings, would be great. Jon Shier ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
