[webkit-qt] QtWebKit --minimal build with minimal Qt
jarred at sencha.com
Wed Sep 28 09:18:29 PDT 2011
On Wed, Sep 28, 2011 at 12:14 PM, <laszlo.1.gombos at nokia.com> wrote:
> >>>>> If we don't support QT_NO_* officially and let the community fix
> >>>>> problems, we have to disable CONFIG+=qt_minimal on this bot,
> >>>>> because a core builder must be green almost at all times.
> >>>> IMO that's sensible. Do we provide guidance for people who want to
> >>>> maintain their own bots where they can test those configurations?
> >>> I agree. Having a core builder that builds a minimal _WebKit_ build
> >>> is something we should strive for, and enabling CONFIG+=qt_minimal
> >>> makes that bot more fragile and less useful for other ports
> >> Seconded. The Qt Minimal bot should be minimal WebKit, and that's
> >> already on the edge of what we can reasonably expect non-Qt WebKit
> >> contributors to care about. I'm fine with keeping the QT_NO_* stuff in
> >> place if it's explicitly unsupported and doesn't grow into anything
> >> beyond disabled code blocks here and there.
> >Second on this, too.
> >If we keep the QT_NO* guards in tree we have to document somewhere that
> this is not officially supported. The minimal bot is otherwise an important
> one since it is the only one testing the correctness of at least a default
> set of the >gadzillion WebKit guards.
> I would challenge this. I think the problem is that it is a really low bar
> to introduce a new build flag for trunk. We should keep the bar high for not
> only new "WebKit flags" but also for "Qt flags" on the trunk. Allowing a
> flag without a bot is allowing code without auto test. I do not think that
> having flags that almost build is any good.
> I would keep the minimal bot configuration as it is or create a new bot for
> CONFIG+=qt_minimal and enforce that every "Qt flags" is also being tested
> (so that at least it builds all the way).
> I also agree with Andreas that most QT_NO_* defines should go from WebKit
> trunk. We should start a review process and go trough each and every one of
> them one-by-one. *We should consider that some flags might be removed from
> Qt5 anyway.*
This is the reason I segued into Qt5 earlier.
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
Jarred Nicholls, Senior Software Architect
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-qt