[webkit-qt] QtWebKit --minimal build with minimal Qt

laszlo.1.gombos at nokia.com laszlo.1.gombos at nokia.com
Wed Sep 28 09:14:04 PDT 2011


Hi,

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

Laszlo


More information about the webkit-qt mailing list