On Sep 27, 2011, at 3:27 PM, ext Andreas Kling wrote: > Heyo, interesting topic! > > In my opinion all QT_NO_* defines should be dropped from WebKit. I believe > QtWebKit is sufficiently complex that you shouldn't use it without a > fully-featured Qt. >
It only adds to the complexity matrix if we have to support them. But if we allow them in without actively supporting them, letting the community fix problems if they arise, I don't see the downside of keeping them. We've actually been doing that for a while now; some brave souls like Suzuki san were fixing issues with QT_NO_* when they arise; that doesn't add any commitment or cost to anybody else. Especially if all we test in the bot is that it builds, not even run tests. Allowing a low-footprint webkit scratches the itch of many people doing great things; Let's let them keep doing that, while being smart about the cost (which is IMO negligible in this case). > For every additional build-time flag, the complexity matrix grows larger, and > we're not testing any of it beyond building with all those flags enabled > together. If we do need to support that, I'd rather we had a monolithic > USE(LESS_QTWEBKIT) flag rather than separate ones. Those end up being kitchen-sinks… I prefer the current situation. Can you refer to one instance where the QT_NO_* stuff created issues for someone rather than the people who care about it? _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
