Compilation issue with qt

[Ian Wadham]

On 06/06/2013, at 9:02 AM, Lawrence Velázquez wrote:

> On Jun 5, 2013, at 12:03 PM, Nicolas Pavillon <nicos at macports.org> wrote:
> 
>> This error seem to appear because Qt forward-declares random_access_iterator_tag in qiterator.h in the part:
>> #ifdef QT_NO_STL
>> namespace std {
>>    struct bidirectional_iterator_tag;
>>    struct random_access_iterator_tag;
>> }
>> #endif
>> This declaration overrides the ones in std libraries, so that the compiler does not recognise the code in grantlee as being valid, as reported in http://llvm.org/bugs/show_bug.cgi?id=13925.
>> 
>> The fix proposed in the link above is to patch qiterator.h, by suppressing the forward declarations, and include <iterator> instead. I tested it, and this indeed works. However, it seems rather overreaching to have to patch Qt (a huge port), in order to get kdevelop to compile. Would anyone have another idea ?

As an app developer depending on kdelibs and Qt, I shudder at the thought
of making such a core change to Qt in Macports, without being quite sure it is
harmless.  It could get right to the heart of container handling (e.g. QList), for
those apps that use iterators over Qt containers.

> What is the QT_NO_STL macro for? Could the build explicitly undefine it?

Googling on QT_NO_STL reveals a rich range of discussion by leading core
developers of both KDE and Qt.  The easiest thread to follow might be:
http://comments.gmane.org/gmane.comp.lib.qt.devel/1670
and it is fairly recent.

From what I can gather, QT_NO_STL is intended for platforms where the
standard C++ library (STL/std) is not available.

It might be a good idea to contact the Qt developers about this issue.

OTOH it is maybe a Clang-related issue, as noted in Michael Dickens' post
and attachment.  KDE is not Clang-ready yet and maybe Qt 4 is not.

Apologies if I do not know what I am talking about.  This stuff is outside my area.

Cheers, Ian W.