libqtmimetypes ?

[Alexander Neundorf]

On Sunday 13 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Sunday 13 May 2012, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> >> > On Sunday 13 May 2012, Stephen Kelly wrote:
> >> >> Alexander Neundorf wrote:
> >> >> > Hi,
> >> >> > 
> >> >> > in libinqt5/src/ there is a libqtmimetypes.
> >> >> > This contains again a complete project.
> >> >> > Is this supposed to be buildable standalone, or always only inside
> >> >> > libinqt5 ?
> >> >> 
> >> >> It used to buils standalone, but Rolf Eike Beer moved it around for
> >> >> his own packaging reasons I think.
> >> >> 
> >> >> I think you should ignore libinqt5, libqt5staging and libqtmimetypes.
> >> >> They don't need to build standalone and their existence is just
> >> >> temporary while frameworks is source compatible with Qt 4 and while
> >> >> the libqt5staging stuff isn't upstream in Qt.
> >> >> 
> >> >> In the greater frameworks plan (ie in terms of what we will release),
> >> >> they are completely irrelevant.
> >> > 
> >> > Yes, I know, but I can't ignore them.
> >> > When trying to build something in e.g. tier1/ standalone, I don't have
> >> > the kdelibs environment around.
> >> > So if it uses something from libinqt5, it must find the installed
> >> > libinqt5, same for qtmimetypes and for kdeqt5staging.
> >> > 
> >> > The current situation is really quite complicated for the buildsystem,
> >> > we have four ways to build:
> >> > * Qt4, all in one
> >> > * Qt4, standalone
> >> > * Qt5, all in one
> >> > * Qt5, standalone
> >> > 
> >> > Getting and then keeping them all four working at the same time is
> >> > hard.
> >> 
> >> Yes, but for you only the ones building against Qt 5 are relevant
> >> really.
> >> 
> >> Also, if you build against Qt 5, then libinqt5 and libqtmimetypes are no
> >> longer needed. Then only kdeqt5staging is needed and even then only for
> >> kcoreaddons, not all frameworks, so it's less of a big deal.
> >> 
> >> There's no point in making efforts to build standalone against Qt 4.
> >> Support for building against Qt 4 is not going to remain long enough for
> >> that to be relevant.
> > 
> > I was happy until now that it still works with Qt4.
> > Are there plans when to stop supporting building against Qt4 ?
> 
> 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

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

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

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

Why ?
 
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120513/af2aef03/attachment-0001.html>