libqtmimetypes ?

[Alexander Neundorf]

On Sunday 13 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
...
> > 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.

I thought a bit more about it in the meantime.
We can make it work by ignoring the exported targets (and all their nice 
properties) for the moment and simply do something like the following in the 
Config files:

find_library(_ at PROJECT_NAME@_LIBRARY NAMES @PROJECT_NAME@
             PATHS ${@PROJECT_NAME at _LIBRARY_DIR}
             NO_DEFAULT_PATH)

add_library(@PROJECT_NAME@ IMPORTED)

set_target_properties(@PROJECT_NAME@ PROPERTIES LOCATION ...)

set(@PROJECT_NAME at _LIBRARY ${_ at PROJECT_NAME@_LIBRARY})

It's a pity that it will still not be like it should be, i.e. we still cannot 
point people to it for a good example (I'd like to get to this state as soon 
as possible).
But it will make it work.
Not sure I'll find the time to do it the coming week.
 
> >> 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.

Comparing benefit and effort, it doesn't seem too bad 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 :).

Thanks for the answer :-)

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120513/f43fb883/attachment-0001.html>