[webkit-dev] Proposal for a new way to handle porting #ifdefs

Maciej Stachowiak mjs at apple.com
Sun May 24 22:08:17 PDT 2009

On May 24, 2009, at 9:28 PM, Peter Kasting wrote:

> On Sun, May 24, 2009 at 12:19 AM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
> On May 23, 2009, at 9:38 AM, David Kilzer wrote:
>> There are essentially two options here:
>> 1. Add #if/#endif guards to entire source files, but include every  
>> file in every build system.
>> 2. Make each build system smart enough to exclude source files that  
>> implement a feature, thus pushing the policy decision down (up?)  
>> into the build system (which is where most of the decisions are  
>> made today anyway).
> I know there is a potential compile time tradeoff, but in some ways  
> it would be nicer if all build systems built the same set of files,  
> and we ifdef'd the contents. That would put the policy decisions all  
> in one place (the port header).
> It seems like build systems will already differ insofar as they  
> include various explicitly platform-specific files  
> ("foo_bar_gtk.cc") so differing more doesn't seem to hurt much.

We could actually avoid that by having all ports include FooBar.cpp in  
the build, and that file conditionally #includes the appropriate port- 
specific implementation.

> My bias is always against #ifdefs so I feel more like David Kilzer  
> does -- option #2 feels a lot cleaner to me.

ifdefs can be messy, but at least the conditional logic becomes  
explicit in the code, instead of being buried in various build  
systems. I think the the only serious downside is the potential to  
increase compile time.

> On the other hand my experience is much more with Chromium ports  
> instead of WebKit ports so my opinion should probably be discounted :)

I don't think it should be discounted. It might be helpful to clarify  
why you think ifdefs are a bad solution.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090524/eb474a74/attachment.html>

More information about the webkit-dev mailing list