please make it easier to hack on frameworks

[Stephen Kelly]

Alexander Neundorf wrote:

>> 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 ? 

If you're working with unreleased software without fine-grained versioning 
(qt5 dev branch), then yes. That's the assumption everyone else has. 

I've never seen a newbie have a problem with the concept of 'my build of foo 
didn't work - I'll update bar', so I don't think it's an important issue to 
invest time or effort in.

> Then this means I should not consider
> a successful cmake run as a reliable signal that my system is ready to
> build the software ? 

Correct. You should not consider that a signal of anything, and I don't know 
why you did assume it was a signal of something without testing that 
assumption.

You are not working with a release of Qt 5, so you can't expect anything. 
Replace 'Qt 5' with any other software in that sentence and it is still 
true. 

Imagine you use FindPNG.cmake to find a dev version of libpng with two new 
API features, one added 6 months ago the other added 2 days ago, but the 
version of libpng didn't get updated in the repo in that time. Can you 
easily determine at cmake time whether you can use the 2 day old feature (or 
even the 6 month old feature)? Not without writing and maintaining a 
configure check downstream. That is not worth it for us.

I don't see why you automatically assume magic without testing the magic. Qt 
5 version does not include a datestamp like cmake does, and it (thankfully) 
doesn't install to a micro-versioned directory like you insist ecm does. You 
are familiar enough with kf5 to know that we don't have cmake configure 
checks for each new Qt 5 C++ API or CMake API we want to use.

How did you expect such a micro-version check was already working for Qt 5? 
Really. I'd like to know what you assumed had happened to make that work.

My suggestion to adjust your expectations to remove expectation of magic 
stands. That will bring your expectations in line with everyone elses.

Thanks,

Steve.