On Tuesday 14 May 2013 17:55:42 Alexander Neundorf wrote: > Do you say I should adjust my expectations so that I consider build > failures ok even if cmake succeeds ? Then this means I should not consider > a successful cmake run as a reliable signal that my system is ready to > build the software ?
This is a never attainable goal: if I remove $QTDIR/include/qlabel.h by hand, I'll get a compilation failure even though cmake will succeed. Does this mean cmake should check that *all* Qt headers are available, one by one? It never did that, and I don't think this is what you have in mind. So you two will only ever agree, if you forget about the extremes :) Both extremes are unacceptable (cmake failing to detect even very basic issues like Qt 5 being 5.0 instead of 5.2 -- and the other extreme, cmake should check all Qt headers one by one). So this is about defining what belongs to the configure step of cmake, i.e. where to draw the line. * Detecting that Qt is recent enough -- I would say yes, cmake should do that. * Detecting completely missing Qt submodules -- I would say yes, cmake should do that. But this particular point is what this discussion is about, so let's focus on that, see below. * Detecting other weird results of a broken Qt build, such as individual missing libs or headers, or broken export macros, or whatever else could go wrong due to bugs in Qt or in qmake -- I would say no, cmake should not do that. The reason I agree that cmake should detect missing Qt submodules, is that even though the current instructions say "compile all of qt5.git", the whole point of qt5 is to be modular, and a future kde hacker getting his qt5 from his distro could be missing a development package for a specific module. So, if code uses qtx11extras, cmake should warn if qtx11extras is not found. Same for all other submodules. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
