[Development] About pcre in qt5

[tasuku.suzuki at nokia.com]

Hi,

I have fixed qconfig and QT_NO_FEATURE builds in Qt 4.6 and 4.7. I just started fixing them in Qt 5 a month ago. You can see some of them here [1]. As Thiago said, they are not supported and tested. But you are able to fix and use them if you really need to reduce the footprint.

Disabling PCRE makes sense for me. As we have QT_NO_REGEXP already, add it to feature list and fix the build.

QT_NO_CURSOR is not fixed yet. So you have to fix it. I'm happy to test and review your patch. Because QCursor::pos() is used in many places, we might use simplified version [2] that is broken (I think) at the moment. If you need to fix errors in QT_FOR_EACH_STATIC_CORE_CLASS, the patch attached may help.

QT_NO_DATASTREAM is the one I'd like to remove in Qt 5 because it is not maintained for a long time.

[1] https://codereview.qt-project.org/#q,tasuku.suzuki@nokia.com,n,z
[2] https://qt.gitorious.org/qt/qtbase/blobs/master/src/gui/kernel/qcursor.h#line56
--
Tasuku Suzuki

On 2012/06/07, at 3:02, ext Brett Stottlemyer wrote:

>>> And also, we find that so many feature flags can't be easily disabled 
>>> for
>>> example: QT_NO_DATASTREAM etc., as it seems many codes are not fully 
>>> controlled on some feature flag. So is that caused as the Qt5 code 
>>> refine ??
>> 
>> Tasuku Suzuki has been trying to fix the feature system, but I guess he
> hasn't managed all combinations yet. Try 
>> talking to him and coordinating your efforts to get this fixed.
>> 
>> Right now, please understand that if you turn *any* of the feature flags
> (that is, if you disable any API), you're > in wholly uncharted territory
> and completely unsupported. Those combinations are not tested by the CI
> system and I  > doubt anyone except Suzuki-san has tried running with them.
> 
> 
> I'm hitting the same issue the QT_NO_CURSOR.  If I don't compile with this
> flag, apps crash because the cursor isn't built onto the device.  QCursor
> has no constructor when compiled with QT_NO_CURSOR, but the QMetatype seems
> to assume it is there.  That is QT_FOR_EACH_STATIC_CORE_CLASS includes
> QCursor, and the FOR_EACH crashes trying to create meta information and is
> also used to create QVariant support (which breaks without a public
> constructor as explained in the QVariant docs).
> 
> Does Suzuki-san follow this list?  Hopefully compiling without a cursor
> isn't an edge case and this can be addressed in Qt5.
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cursor.patch
Type: application/octet-stream
Size: 915 bytes
Desc: cursor.patch
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120610/50a49696/attachment.obj>