Well, here it's patch, based on qt4-r2 build. It seems to be working. Changes EAPI supported from 2,3,4,5 to 4,5 (reason: new Qt5 ebuild can use lastest EAPI) Renamed Qt4 => Qt5 Renamed eqmake4 => eqmake5 After including Qt5 I have prepared qtwayland ebuild and SnowShoe web browser (depend on Qt5) Reproducible: Always
Created attachment 346770 [details] qt5-eclass-patch.diff
Thanks for your contribution. A few comments: 1) I would like to see a minimum of EAPI=5 enforced for qt5 ebuilds 2) l10n.eclass should be used for localization handling, not the old method from our qt4 eclass 3) I would like to see a review of eqmake5 function before we commit this from one of our more experienced eclass hackers
https://github.com/okias/qt/blob/master/eclass/qt5.eclass changelog ========== * EAPI 5 only * removed EAPI 2 EPREFIX hack * removed qt5_install_translations and reference Please review, thank you
also completly removed LANG handling
The eclass looks good to me in the sense that we know the existing eqmake4 one works as expected. indeed eqmake5 may need some kind of review but the thing is we don't have many Qt5 apps around to test it thoroughly
https://github.com/okias/qt/blob/master/eclass/qt5.eclass could I do Pull merge? If no objection will be raised, we could improve it later.
I'm not totally happy with this approach. I don't think we should start from qt4-r2.eclass and "port" it to qt5. We should rather write the new one from scratch, based on more modern eclasses such as multibuild and multilib-build.
(In reply to comment #7) > I'm not totally happy with this approach. I don't think we should start from > qt4-r2.eclass and "port" it to qt5. We should rather write the new one from > scratch, based on more modern eclasses such as multibuild and multilib-build. why do you want to start from scratch?
(In reply to comment #8) Because, as I said, I'd like to base qt5.eclass on eclasses such as multibuild and multilib-build, whose design is quite different from the current qt4-r2.eclass. This will enable us to support e.g. out-of-source builds, multiple build variants (shared/static), multilib, and so on. The only thing that can be "ported" is eqmake4(), except for the CONFIG fixing, which should be done only in packages that require it (and a patch sent upstream).
Well, number of QT 5 application gains every day, if no one step up with rewritten qt5 eclass, we could accept simple qt5.class (based on qt4.eclass). If it will be needed, someone step up and rewrite it later :) Any ideas?
Should we call the eclass qmake5 or something instead? I remember from the qt4 -> qt4-r2 conversion there were a number of packages inheriting the eclass but not actually needing or using it in any way.
(In reply to Michael Palimaka (kensington) from comment #11) > Should we call the eclass qmake5 or something instead? I remember from the > qt4 -> qt4-r2 conversion there were a number of packages inheriting the > eclass but not actually needing or using it in any way. I've been thinking about that too. A "simple" qmake-utils.eclass containing only eqmake{4,5}() and not exporting any phase functions. qt4-r2 and qt5 eclasses can then inherit it and implement some phase functions and do more advanced stuff such as out-of-source builds and multilib. Thoughts?
(In reply to Michael Palimaka (kensington) from comment #11) > Should we call the eclass qmake5 or something instead? I remember from the > qt4 -> qt4-r2 conversion there were a number of packages inheriting the > eclass but not actually needing or using it in any way. I don't see why. qt5 is short and to the point. IIRC, repoman complains these days if an eclass is inherited but not used.
(In reply to Davide Pesavento from comment #12) > I've been thinking about that too. A "simple" qmake-utils.eclass containing > only eqmake{4,5}() and not exporting any phase functions. qt4-r2 and qt5 > eclasses can then inherit it and implement some phase functions and do more > advanced stuff such as out-of-source builds and multilib. > > Thoughts? I like the idea of qmake-utils and it could help with packages supporting both qt4 and 5 - no need to necessarily include two eclasses and juggle which phases to call. I do wonder if providing an extra full-blown eclass with phases is overkill. It looks like an eclass such as multilib-minimal can work with qmake nicely while supporting out-of-source and multilib. (In reply to Ben de Groot from comment #13) > I don't see why. qt5 is short and to the point. The eclass is about supporting qmake rather than qt, so I think the name should reflect that. qmake-utils for example is consistent with other eclasses like cmake-utils and autotools-utils. > IIRC, repoman complains these days if an eclass is inherited but not used. This check is hard-coded for certain functions in certain eclasses only.
(In reply to Michael Palimaka (kensington) from comment #14) > (In reply to Ben de Groot from comment #13) > > I don't see why. qt5 is short and to the point. > The eclass is about supporting qmake rather than qt, so I think the name > should reflect that. qmake-utils for example is consistent with other > eclasses like cmake-utils and autotools-utils. Ah, I guess there is something to be said for that. > > IIRC, repoman complains these days if an eclass is inherited but not used. > This check is hard-coded for certain functions in certain eclasses only. Thanks for clarifying.
http://git.overlays.gentoo.org/gitweb/?p=proj/qt.git;a=commitdiff;h=d11a5636128d2fa3c8be327e270396e9879d113b I'm considering this fixed for now. Please file a new report for bugs, improvements, feature additions, better eclass design, etc..
just FYI - eqmake5 you could at least once test eqmake5.. it segfauls on all instalations.
sorry, it compiles and then die on sandbox violation when installing, you could test atleast one package I did :(
