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

[Peter Kasting]

On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak <mjs at apple.com> wrote:

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

Generally they make it more difficult to read the code (which is what I
spend 99% of the time doing) without really making it easier to find what's
in the build (which I only spend 1% of the time doing anyway).  The reason
for this latter is because there's a lot of files that look like they're
included but I actually don't care about, while if you go the "#include
foo_bar_gtk.cc" route to handle port-specific implementations, it can make
it harder for your IDE to determine that foo_bar_gtk.cc is an important file
(e.g. by doing "open foo_bar_gtk.cc" in its command line).  (This depends on
the IDE, of course.)

I would prefer to optimize for reading the code for my port, which generally
means as few #ifdefs as possible, and pushing as much logic into the build
system as possible (by including or not including various files).  It
implies things like preferring per-port subclasses to port-specific members
in the parent class, preferring to not include files rather than #ifdef
their contents away... basically, the opposite of all the decisions WebKit
looks to have taken :D

I don't think this is a big deal for most things, and I think the cases
where it is a big deal have been dealt with well when they've come up in the
past (from what I've seen as a third party -- usually Darin Fisher or
someone else on the team is running into them), so don't take this as a
disgruntled complaint against the current system.  It's just my preference.

Now, the thing I _would_ like to change is to switch from pathless #includes
to ones with relative paths -- but that's a totally different thread.

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