Re: [OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools
On Wednesday 04 November 2015 23:10:26 René J. V. Bertin wrote: > Alex Merry wrote: > > > > Well, if we'd done it for kdelibs4 as well, you wouldn't have this issue > > - if you had to add -I/opt/local/include/kdelibs in order to find any > > kdelibs headers, none would be found by mistake. > > Fair enough, but you didn't :) > > FWIW (and because there are some on here who would like to let KF5 be as > native > as possible on OS X): with Apple's framework bundles that also contain the > headers, you're more or less supposed to use statements like #include > (or #import in ObjC). > Standardising on #include where KFoo is expected to live in a > standard include directory would make it more straightforward to build KF5 > frameworks as OS X frameworks (i.e. bundles). But this would have: - made the porting effort to KF5 even greater, for all the existing code - made it impossible to move classes between frameworks (we've had the issue with in Qt4 being in Qt5. The obvious way to not hit such issues is to make it everywhere, which is now indeed the recommended way). These are the reasons why Qt decided on and we decided on . Get your kdelibs4 headers out of the way and everything will be fine :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools
Alex Merry wrote: > Looks like your include path is wrong. /opt/local/include/KF5/KArchive > should be in the include path (before wherever wherever your kdelibs4 > headers are). I suppose you're right, but AFAIK I don't do anything either to alter the install location (relative to /opt/local) nor to alter the include path. Would that also fix the error related to KARCHIVE_DEPRECATED, in other words, am I missing a header that defines that token because /opt/local/include/KF5/KArchive isn't on the include path? R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools
Alex Merry wrote: > Well, if we'd done it for kdelibs4 as well, you wouldn't have this issue > - if you had to add -I/opt/local/include/kdelibs in order to find any > kdelibs headers, none would be found by mistake. Fair enough, but you didn't :) FWIW (and because there are some on here who would like to let KF5 be as native as possible on OS X): with Apple's framework bundles that also contain the headers, you're more or less supposed to use statements like #include (or #import in ObjC). Standardising on #include where KFoo is expected to live in a standard include directory would make it more straightforward to build KF5 frameworks as OS X frameworks (i.e. bundles). R ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools
René J. V. Bertin wrote: > Alex Merry wrote: > >> Looks like your include path is wrong. /opt/local/include/KF5/KArchive >> should be in the include path (before wherever wherever your kdelibs4 >> headers are). In fact: cd /opt/local/var/macports/build/_opt_local_site-ports_kf5_Frameworks/kf5- kdoctools/work/build/src && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -DQT_CORE_LIB -DQT_MAC_USE_COCOA -DQT_NO_CAST_FROM_BYTEARRAY - DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS - DQT_NO_URL_CAST_FROM_STRING -DQT_QSP_XDG_LIB -DQT_USE_FAST_OPERATOR_PLUS - DQT_USE_QSTRINGBUILDER -DTRANSLATION_DOMAIN=\"kdoctools5\" -D_DARWIN_C_SOURCE - D_LARGEFILE64_SOURCE -O3 -march=native -g -DNDEBUG -stdlib=libc++ -std=c++0x - fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security - Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual - Werror=return-type -pedantic -Wno-gnu-zero-variadic-macro-arguments -mmacosx- version-min=10.9 -I/opt/local/var/macports/build/_opt_local_site- ports_kf5_Frameworks/kf5-kdoctools/work/build/src - I/opt/local/var/macports/build/_opt_local_site-ports_kf5_Frameworks/kf5- kdoctools/work/kdoctools-5.15.0/src -I/opt/local/include/libxml2 - I/opt/local/include -iframework /opt/local/libexec/qt5/Library/Frameworks - isystem /opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Headers - isystem /opt/local/share/qt5/mkspecs/macx-clang -isystem /opt/local/libexec/qt5/Library/Frameworks/QtQspXDG.framework/Headers -isystem /opt/local/include/KF5/KArchive -isystem /opt/local/include/KF5-fPIC -o CMakeFiles/meinproc5.dir/xslt_kde.cpp.o -c /opt/local/var/macports/build/_opt_local_site-ports_kf5_Frameworks/kf5- kdoctools/work/kdoctools-5.15.0/src/xslt_kde.cpp looking closely enough, you'll see that there's (in that order) -I/opt/local/include -isystem /opt/local/include/KF5/KArchive so it's perfectly correct that the KDE4 header is picked up first. And the KARCHIVE_DEPRECATED error is explained the same way: the KDE4 karchive_export.h header is found before the KF5 one ... I must admit I don't really see the point in bundling headerfiles in a specific directory, only to relinquish the selectivity that allows from #include statements by adding the directory/ies to the -I includepath ... R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools
On 2015-11-04 21:45, René J. V. Bertin wrote: René J. V. Bertin wrote: Alex Merry wrote: Looks like your include path is wrong. /opt/local/include/KF5/KArchive should be in the include path (before wherever wherever your kdelibs4 headers are). In fact: cd /opt/local/var/macports/build/_opt_local_site-ports_kf5_Frameworks/kf5- kdoctools/work/build/src && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -DQT_CORE_LIB -DQT_MAC_USE_COCOA -DQT_NO_CAST_FROM_BYTEARRAY - DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS - DQT_NO_URL_CAST_FROM_STRING -DQT_QSP_XDG_LIB -DQT_USE_FAST_OPERATOR_PLUS - DQT_USE_QSTRINGBUILDER -DTRANSLATION_DOMAIN=\"kdoctools5\" -D_DARWIN_C_SOURCE - D_LARGEFILE64_SOURCE -O3 -march=native -g -DNDEBUG -stdlib=libc++ -std=c++0x - fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security - Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual - Werror=return-type -pedantic -Wno-gnu-zero-variadic-macro-arguments -mmacosx- version-min=10.9 -I/opt/local/var/macports/build/_opt_local_site- ports_kf5_Frameworks/kf5-kdoctools/work/build/src - I/opt/local/var/macports/build/_opt_local_site-ports_kf5_Frameworks/kf5- kdoctools/work/kdoctools-5.15.0/src -I/opt/local/include/libxml2 - I/opt/local/include -iframework /opt/local/libexec/qt5/Library/Frameworks - isystem /opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Headers - isystem /opt/local/share/qt5/mkspecs/macx-clang -isystem /opt/local/libexec/qt5/Library/Frameworks/QtQspXDG.framework/Headers -isystem /opt/local/include/KF5/KArchive -isystem /opt/local/include/KF5 -fPIC -o CMakeFiles/meinproc5.dir/xslt_kde.cpp.o -c /opt/local/var/macports/build/_opt_local_site-ports_kf5_Frameworks/kf5- kdoctools/work/kdoctools-5.15.0/src/xslt_kde.cpp looking closely enough, you'll see that there's (in that order) -I/opt/local/include -isystem /opt/local/include/KF5/KArchive so it's perfectly correct that the KDE4 header is picked up first. And the KARCHIVE_DEPRECATED error is explained the same way: the KDE4 karchive_export.h header is found before the KF5 one ... I must admit I don't really see the point in bundling headerfiles in a specific directory, only to relinquish the selectivity that allows from #include statements by adding the directory/ies to the -I includepath ... Well, if we'd done it for kdelibs4 as well, you wouldn't have this issue - if you had to add -I/opt/local/include/kdelibs in order to find any kdelibs headers, none would be found by mistake. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools
On 2015-11-04 15:53, René J.V. Bertin wrote: Hi, Building KF5/kdoctools 5.15.0 on OS X, I run into 2 issues: - the #include statement finds the corresponding header from KDELibs4 - after changing the statement into #include (which I think it should be anyway?), I get the error In file included from /opt/local/var/macports/build/_opt_local_site-ports_kf5_Frameworks/kf5-kdoctools/work/kdoctools-5.15.0/src/xslt_kde.cpp:2: /opt/local/include/KF5/KArchive/kfilterdev.h:95:5: error: unknown type name 'KARCHIVE_DEPRECATED' KARCHIVE_DEPRECATED static KCompressionDevice *deviceForFile(const QString , ^ /opt/local/include/KF5/KArchive/kfilterdev.h:95:25: error: expected member name or ';' after declaration specifiers KARCHIVE_DEPRECATED static KCompressionDevice *deviceForFile(const QString , ~~~ ^ I take it that I could #define KARCHIVE_DEPRECATED to get around this, but I have a hunch I shouldn't be getting the warning in the 1st place? Looks like your include path is wrong. /opt/local/include/KF5/KArchive should be in the include path (before wherever wherever your kdelibs4 headers are). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
