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

[Maciej Stachowiak]

On May 24, 2009, at 10:51 PM, Peter Kasting wrote:

> 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'll agree that a bunch of #ifdefs in the middle of code can be hard  
to read. In general though, I'm not sure that optimizing for only  
thinking about one port is the right approach. Ideally, we should both  
make it easy to work on only port-level stuff, *and* make it practical  
for people doing core work with port-specific implications to do what  
they need to do. I would even argue we should prioritize ease of core  
work over ease of port-specific work, if we should ever face that  
tradeoff.

>
> 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.

That I definitely wouldn't like. It would make it much more painful to  
move files. What is the benefit? Maybe UI am missing something.

Regards,
Maciej

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