Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 467712 - [qt overlay] qt5.eclass addition request
Summary: [qt overlay] qt5.eclass addition request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All All
: Normal enhancement (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords: InOverlay
Depends on:
Blocks: 461584 468328
  Show dependency tree
 
Reported: 2013-04-28 09:38 UTC by David Heidelberg (okias)
Modified: 2014-03-18 22:43 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
qt5-eclass-patch.diff (qt5-eclass-patch.diff,10.96 KB, text/plain)
2013-04-28 09:41 UTC, David Heidelberg (okias)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Heidelberg (okias) 2013-04-28 09:38:03 UTC
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
Comment 1 David Heidelberg (okias) 2013-04-28 09:41:01 UTC
Created attachment 346770 [details]
qt5-eclass-patch.diff
Comment 2 Ben de Groot (RETIRED) gentoo-dev 2013-04-29 08:08:54 UTC
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
Comment 3 David Heidelberg (okias) 2013-04-29 08:57:18 UTC
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
Comment 4 David Heidelberg (okias) 2013-04-29 09:11:04 UTC
also completly removed LANG handling
Comment 5 Markos Chandras (RETIRED) gentoo-dev 2013-04-29 09:23:41 UTC
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
Comment 6 David Heidelberg (okias) 2013-05-02 19:00:24 UTC
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.
Comment 7 Davide Pesavento gentoo-dev 2013-05-02 20:08:28 UTC
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.
Comment 8 Markos Chandras (RETIRED) gentoo-dev 2013-05-03 15:07:51 UTC
(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?
Comment 9 Davide Pesavento gentoo-dev 2013-05-04 09:18:43 UTC
(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).
Comment 10 David Heidelberg (okias) 2013-05-26 09:44:31 UTC
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?
Comment 11 Michael Palimaka (kensington) gentoo-dev 2013-05-27 15:47:49 UTC
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.
Comment 12 Davide Pesavento gentoo-dev 2013-05-27 23:11:48 UTC
(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?
Comment 13 Ben de Groot (RETIRED) gentoo-dev 2013-05-28 12:26:36 UTC
(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.
Comment 14 Michael Palimaka (kensington) gentoo-dev 2013-05-28 15:07:18 UTC
(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.
Comment 15 Ben de Groot (RETIRED) gentoo-dev 2013-05-28 15:46:16 UTC
(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.
Comment 16 Davide Pesavento gentoo-dev 2013-05-31 09:10:10 UTC
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..
Comment 17 David Heidelberg (okias) 2013-06-08 13:45:05 UTC
just FYI - eqmake5 you could at least once test eqmake5.. it segfauls on all instalations.
Comment 18 David Heidelberg (okias) 2013-06-08 13:52:33 UTC
sorry, it compiles and then die on sandbox violation when installing, you could test atleast one package I did :(