[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.
Regards,
Maciej
-------------- 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