[webkit-dev] Proposal for a new way to handle porting #ifdefs
pkasting at google.com
Sun May 24 22:51:55 PDT 2009
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev