please make it easier to hack on frameworks

[David Faure]

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, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5