please make it easier to hack on frameworks

[Alexander Neundorf]

On Tuesday 14 May 2013, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Additionally we don't check in cmake that the Qt which has been found is
> > good enough.
> > We make use of the new INTERFACE_INCLUDE_DIRECTORIES target property, but
> > have no checks that the Qt which has been found provides those already.
> > 
> > The obvious way would be by requiring some specific minimum version
> > number of Qt.
> > Stephen, is this possible ?
> 
> I've bumped the required Qt version to 5.2.0, which is what the dev branch
> happens to identify itself as currently.

Thanks :-)
 
> > Stephen, what is your plan regarding this ?
> 
> The real problem here is one of expectations. Therefore, you might have
> similar issues in the future.
> 
> For the sake of future proofing, I suggest you adjust your expections as
> follows:
> 
> 1) If you can't build frameworks, and it is possible to update your Qt
> build, then update your Qt build. Don't expect to get an error at cmake
> time.
> 2) If you update your Qt repos, do a clean build and a clean install. Don't
> expect a dirty build to work.
> 
> From reading your emails, it looks like your existing expectations are the
> opposite of the above, though I don't know why.

There shall be no build failure due to bad includes or libs if cmake says 
everything is ok.
That's the point of the configure step of cmake.
This is how I know cmake, and what I'm trying to keep true since I'm working 
on buildsystems, and that's why these are my expectations.

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 ?
Or do you mean just for frameworks development ?

IMO this is not a good policy.
See the subject.

Alex