libqtmimetypes ?

[Stephen Kelly]

Alexander Neundorf wrote:

>> We'll still keep it possible to build with Qt 4 for some months yet.
>> Probably as long as it's still useful. Currently it is useful because the
>> output of unit tests can show whether failures result from frameworks
>> code or Qt 5 changes.
>> 
>> What I mean though is that building standalone frameworks against Qt4
>> isn't something we should put any effort into IMO.
> 
> This still leaves three options to support
> * Qt4, all
> * Qt5, all
> * Qt5, standalone

Yes, although until either 

* we have the new CMake feature from Yury, or
* we have split repos

I don't think we need to put too much effort into trying to make tier2 
libraries use installed tier1 libraries built stand-alone (except 
experimentally). This is also what you suggest below.

So that just leaves building all against Qt 4 or Qt 5. 

Most people build against Qt 4 already currently, but it's not the way for 
the future (We will never support it, or at least I won't). 

So unless you're interested in running the unit tests for regressions (which 
is of course important, but either you'll do it or you won't...), it's 
probably more useful for most people to build frameworks against Qt 5.

> As long as we support building all in one go, everything is in one
> repository. Currently, in this case, as you know we cannot really use the
> exported targets from cmake.

Yes.

> This means either we need to put a lot of work in the buildsystem, to
> handle all cases correctly (and clean up afterwards again), or we don't
> support building standalone for anything tier>1 at all, also with Qt5,
> until either the split has happened or cmake got the new feature from
> Yury.

Yes, this is what I would suggest is smartest at the moment.

> 
>> If we can build all of
>> frameworks against Qt 4 at once, that's enough for the unit test
>> verification.
>> 
>> Not having enough people building against Qt 5 is a source of bugs (eg
>> the fPIE bug) because I was building Qt with -no-reduce-relocations,
>> which isn't the default.
>> 
>> We only saw the extent of the problem with that when David tried to build
>> frameworks with Qt 5. When the next person does, we may hit other issues,
> 
> That would be an argument for requiring Qt5 IMO.

What do you mean requiring? Not allowing building against Qt 4? 

Building against Qt 4 is still useful because the unit tests pass there. If 
they don't pass when built/run against Qt5, that indicates Qt behaviour 
changes, rather than a change introduced in KF5. If we can't verify that the 
tests pass when run against Qt 4, we can't narrow down the cause at all.

Of course we can't keep it working with Qt 4 forever, but for the moment it 
makes sense (at least until we can get the unit tests passing with 
Qt5/frameworks).

> 
>> and the CMake version we will need to depend on will have to keep
>> increasing.
> 
> Why ?

It is not possible to compile code using CMake and Qt 5 unless one of the 
following is true:

* Your Qt is configured with -no-reduce-relocations (as I do)
* You can make your executables be compiled with -fPIE and your shared 
libraries be compiled with -fPIC, which is why I want to add the 
POSITION_INDEPENDENT_CODE property to CMake 2.8.9 and then depend on that.
* You add -fPIC globally to your CMAKE_CXX_FLAGS, which seems like too much 
of a hack to me.
* You use qt5_use_modules, which doesn't have a Qt 4 equivalent (Yet. I want 
to add it there, but that will also be CMake 2.8.9 or later).

This is just one example. As other people attempt to build frameworks with 
Qt 5 (in either the default configuration or common non-default 
configurations) we are likely to see more issues raised which may call for 
new features in CMake that we need to rely on.

Or there could be issues in the Qt 5 CMake files which are critical to KF5, 
but which have not been found yet for the same reasons (configurations 
different to what I use). Then they might not be fixed until Qt 5.1.

Building against Qt 4 will not expose all the issues.

If that's not the answer to your 'Why?' question, then please try a more 
wordy question :).

>  
>> > When building against Qt5, is the alpha ok or is a git clone needed ?
>> 
>> A git clone is needed.
> 
> Hmm.
> Will the beta be good enough ?
> 
> Alex

For a time, possibly. 

If there are API changes after the beta, then it won't be good enough 
anymore. If such API changes happen between the tagging of the beta and the 
release of the beta, then it will not be good enough at any time.

That's unlikely of course, but also something we can't predict.

Thanks,

Steve.