Details
-
User Story
-
Resolution: Duplicate
-
P4: Low
-
None
-
None
-
None
Description
The parse_build_log approach to parsing compiler messages is inherently flawed. Though it generally does a good job, it will always be prone to making minor mistakes, since the build log itself is ambiguous.
Here's an example:
../../include/QtCore/../../src/corelib/tools/qvector.h:72: note: initialized from here
../../include/QtCore/../../src/corelib/tools/qstring.h:907: note: initialized from here
../../include/QtCore/../../src/corelib/tools/qvector.h:72: note: initialized from here
../../include/QtCore/../../src/corelib/tools/qvector.h:279: note: initialized from here
../../include/QtCore/../../src/corelib/tools/qstring.h:907: note: initialized from here
compiling util/qsystemtrayicon_qpa.cpp
../../include/QtCore/../../src/corelib/tools/qstring.h:907: note: initialized from here
../../include/QtCore/../../src/corelib/tools/qvector.h:72: note: initialized from here
util/qsystemtrayicon_qpa.cpp: In member function 'void QSystemTrayIconPrivate::showMessage_sys(const QString&, const QString&, QSystemTrayIcon::MessageIcon, int)':
util/qsystemtrayicon_qpa.cpp:142: error: incomplete type 'QApplication' used in nested name specifier
util/qsystemtrayicon_qpa.cpp:142: error: incomplete type 'QStyle' used in nested name specifier
util/qsystemtrayicon_qpa.cpp:145: error: incomplete type 'QApplication' used in nested name specifier
util/qsystemtrayicon_qpa.cpp:145: error: incomplete type 'QStyle' used in nested name specifier
util/qsystemtrayicon_qpa.cpp:148: error: incomplete type 'QApplication' used in nested name specifier
util/qsystemtrayicon_qpa.cpp:148: error: incomplete type 'QStyle' used in nested name specifier
util/qsystemtrayicon_qpa.cpp:140: warning: enumeration value 'NoIcon' not handled in switch
util/qsystemtrayicon_qpa.cpp:135: warning: unused variable 'q'
make[2]: *** [.obj/release-shared/qsystemtrayicon_qpa.o] Error 1
make[1]: *** [sub-widgets-make_default-ordered] Error 2
make: *** [module-qtbase] Error 2
Here, the script extracted the relevant details, but also various useless " note: initialized from here" messages. The script does this because it has no way of knowing which warning or error the "initialized from here" lines belong to; it has to guess, and in this case it guessed wrong.
It would be nice, though low priority, if we could make the parsing completely accurate. The only way I can think of to do this would be to modify or wrap the compilers, or implement some build system support, capturing and reformatting the compiler's output so that, when a particular file fails to compile, we know exactly what the compiler output for that file.
Attachments
Issue Links
- duplicates
-
COIN-16 parse_build_log.pl needs updates to capture more info
-
- Open
-