On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak <[email protected]> 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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
