Re: [gentoo-dev] RFC: qt4-r2.eclass - new eclass for Qt-based apps
On Sunday 29 November 2009 13:46:59 Dominik Kapusta wrote:
Hello guys!
We, the Qt team, would like to include a new eclass in the tree.
The qt4-r2 eclass is meant to help with ebuilds for Qt-based (qmake-based,
to be precise) applications.
The eclass is attached, and here's a short comparison between qt4-r2 and
qt4 (currently in tree) eclasses:
Removed in qt4-r2:
* obsolete QT4_BUILD_WITH_USE_CHECK and
QT4_OPTIONAL_BUILD_WITH_USE_CHECK hacks.
Improved in qt4-r2:
* eqmake4 function now behaves similarly to qmake itself, i.e.:
- doesn't assume ${PN}.pro, but searches for the project file if not
specified, just like qmake does
- in some cases is able to figure out the correct project file if there
are several of them in one directory (rare case, but technically
possible)
New in qt4-r2:
* automatic generation of linguas_* IUSE, based on LANGS and LANGSLONG
variables,
* automatic installation of documentation, based on DOCS and DOCSDIR
variables,
* exported src_configure(), src_compile() and src_install() functions
The qt4-r2 eclass requires EAPI-2.
We have been developing, testing and constantly improving qt4-r2 in
qting-edge overlay for around a year already. It's working for us and we
find it very handy compared to the old qt4.eclass.
After pushing qt4-r2 to the tree, we're going to port Qt 4 apps' ebuilds to
qt4-r2 and deprecate qt4.eclass.
Thanks,
Dominik
Hey,
I'm attaching:
* the eclass updated according to suggestion from scarabeus,
* the diff between the first revision and the current one.
Changes include:
* moving EAPI check to the global scope,
* moving documentation around,
* passing parameters to inner functions (inherited from base.eclass).
Please review this one, if there are no objections we'd like to introduce it
to the tree in about two weeks time starting from now.
Thanks a lot,
Dominik
--- qt4-r2.eclass.orig 2009-12-01 23:26:20.0 +0200
+++ qt4-r2.eclass 2009-12-03 20:36:47.0 +0200
@@ -8,39 +8,46 @@
# Markos Chandras hwoar...@gentoo.org,
# Davide Pesavento davidep...@gmail.com,
# Dominik Kapusta a...@gentoo.org
-# @BLURB: Experimental eclass for Qt4 packages
+# @BLURB: Eclass for Qt4 packages, second edition
# @DESCRIPTION:
# This eclass contains various functions that may be useful when
# dealing with packages using Qt4 libraries. Requires EAPI=2.
+case ${EAPI} in
+ 2) : ;;
+ *) DEPEND=EAPI-INCOMPATIBLE ;;
+esac
+
inherit base eutils multilib toolchain-funcs
export XDG_CONFIG_HOME=${T}
-for x in ${LANGSLONG}; do
- IUSE=${IUSE} linguas_${x%_*}
-done
-
+# @ECLASS-VARIABLE: LANGS
+# @DESCRIPTION:
+# In case your Qt4 application provides various translations, use this variable
+# to specify them in order to populate linguas_* IUSE automatically. Make sure
+# that you set this variable BEFORE inheriting qt4-r2 eclass.
+# example: LANGS=en el de
for x in ${LANGS}; do
IUSE=${IUSE} linguas_${x}
done
-qt4-r2_pkg_setup() {
- case ${EAPI} in
- 2) ;;
- *)
- eerror
- eerror The ${ECLASS} eclass requires EAPI=2, but this ebuild does not
- eerror have EAPI=2 set. The ebuild author or editor failed. This ebuild needs
- eerror to be fixed. Using ${ECLASS} eclass without EAPI=2 will fail.
- eerror
- die ${ECLASS} eclass requires EAPI=2
- ;;
- esac
-}
+# @ECLASS-VARIABLE: LANGSLONG
+# @DESCRIPTION:
+# Same as above, but this variable is for LINGUAS that must be in long format.
+# Remember to set this variable BEFORE inheriting qt4-r2 eclass.
+# Look at ${PORTDIR}/profiles/desc/linguas.desc for details.
+for x in ${LANGSLONG}; do
+ IUSE=${IUSE} linguas_${x%_*}
+done
+# @FUNCTION: qt4-r2_src_unpack
+# @DESCRIPTION:
+# Default src_unpack function for packages that depend on qt4. If you have to
+# override src_unpack in your ebuild (probably you don't need to), call
+# qt4-r2_src_unpack in it.
qt4-r2_src_unpack() {
- base_src_unpack
+ debug-print-function $FUNCNAME $@
# Fallback to ${WORKDIR}/${MY_P} when ${WORKDIR}/${P} doesn't exist.
# Feel free to re-implement this
@@ -48,6 +55,8 @@
ewarn Falling back to '${WORKDIR}/${MY_P}'
S=${WORKDIR}/${MY_P}
fi
+
+ base_src_unpack $@
}
# @ECLASS-VARIABLE: PATCHES
@@ -58,29 +67,6 @@
# PATCHES=( ${FILESDIR}/mypatch.patch
# ${FILESDIR}/mypatch2.patch )
#
-# @ECLASS-VARIABLE: LANGS
-# @DESCRIPTION:
-# In case your Qt4 application provides various translations, use this variable
-# to specify them in order to populate linguas_* IUSE automatically. Make sure
-# that you set this variable BEFORE inheriting qt4-r2 eclass.
-# example: LANGS=en el de
-#
-# @ECLASS-VARIABLE: LANGSLONG
-# @DESCRIPTION:
-# Same as above, but this variable is for LINGUAS that must be in long format.
-# Remember to set this variable BEFORE inheriting qt4-r2 eclass.
-# Look at ${PORTDIR}/profiles/desc/linguas.desc for details.
-#
-# @ECLASS-VARIABLE: DOCS
-# @DESCRIPTION:
-# Use this variable if you want to install any documentation.
-#
Re: [gentoo-dev] RFC: qt4-r2.eclass - new eclass for Qt-based apps
On Sunday 29 November 2009 15:54:30 Thomas Anderson wrote: On Sun, Nov 29, 2009 at 01:46:59PM +0200, Dominik Kapusta wrote: Hello guys! We, the Qt team, would like to include a new eclass in the tree. The qt4-r2 eclass is meant to help with ebuilds for Qt-based (qmake-based, to be precise) applications. Haven't look at the content yet. But the name is going to make things extremely confusing. I can see people using qt4-r2 just because it has -r2 (so it is newer than qt4), even if they should use qt4. If you really need to introduce a new eclass, you should use a name that accurately reflects what it does. Cheers, Thomas The name is actually the simplest possible, and yes, our goal is to switch to qt4-r2 in the end (which I mentioned at the end of my first mail). So in general, once qt4-r2 is in, no one should use qt4.eclass. We had several name options, e.g. qt4-tng but qt4-r2 seemed the most straightforward. plus -r2 adds the Gentoo flavor, hence is better than e.g. qt4-v2 :) That said, we want qt4-r2 to be a new eclass for Qt-based ebuilds. And we can't just make changes to qt4.eclass since there are too many ebuilds using it and we would surely break the tree. Cheers, Dominik signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: qt4-r2.eclass - new eclass for Qt-based apps
On Sunday 29 November 2009 16:29:51 Dominik Kapusta wrote: On Sunday 29 November 2009 15:54:30 Thomas Anderson wrote: On Sun, Nov 29, 2009 at 01:46:59PM +0200, Dominik Kapusta wrote: Hello guys! We, the Qt team, would like to include a new eclass in the tree. The qt4-r2 eclass is meant to help with ebuilds for Qt-based (qmake-based, to be precise) applications. Haven't look at the content yet. But the name is going to make things extremely confusing. I can see people using qt4-r2 just because it has -r2 (so it is newer than qt4), even if they should use qt4. If you really need to introduce a new eclass, you should use a name that accurately reflects what it does. Cheers, Thomas The name is actually the simplest possible, and yes, our goal is to switch to qt4-r2 in the end (which I mentioned at the end of my first mail). So in general, once qt4-r2 is in, no one should use qt4.eclass. We had several name options, e.g. qt4-tng but qt4-r2 seemed the most straightforward. plus -r2 adds the Gentoo flavor, hence is better than e.g. qt4-v2 :) That said, we want qt4-r2 to be a new eclass for Qt-based ebuilds. And we can't just make changes to qt4.eclass since there are too many ebuilds using it and we would surely break the tree. Cheers, Dominik Scarabeus ( Tomas ) proposed this patch [1]. I think it is ok to apply it [1]: http://dev.gentoo.org/~scarabeus/qt4-r2.eclass.patch -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise/Kernel/Bug-wrangler] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: qt4-r2.eclass - new eclass for Qt-based apps
2009/11/29 Thomas Anderson tander...@gentoo.org: I can see people using qt4-r2 just because it has -r2 (so it is newer than qt4) That is exactly the intended behaviour. We would break the tree if we would simply add the new functionality to the existing qt4.eclass. And in absence of an eclass versioning mechanism, this is what we came up with. As soon as existing ebuilds in the tree are ported over to qt4-r2, the old qt4.eclass will be removed. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] RFC: qt4-r2.eclass - new eclass for Qt-based apps
2009/11/29 Dawid Węgliński c...@gentoo.org: On Sunday 29 November 2009 16:59:10 Ben de Groot wrote: As soon as existing ebuilds in the tree are ported over to qt4-r2, the old qt4.eclass will be removed. As far as i remember we don't remove eclasses. Probably you meant deprecated, but not removed? I hate leaving old cruft around, so I definitely meant removed. If that is against policy, can you refer me to a document that specifies said policy? Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] RFC: qt4-r2.eclass - new eclass for Qt-based apps
On Monday 30 November 2009 00:19:49 Ben de Groot wrote: 2009/11/29 Dawid Węgliński c...@gentoo.org: On Sunday 29 November 2009 16:59:10 Ben de Groot wrote: As soon as existing ebuilds in the tree are ported over to qt4-r2, the old qt4.eclass will be removed. As far as i remember we don't remove eclasses. Probably you meant deprecated, but not removed? I hate leaving old cruft around, so I definitely meant removed. If that is against policy, can you refer me to a document that specifies said policy? Cheers, Sorry, i was not up to date with this. http://devmanual.gentoo.org/eclass-writing/index.html -- Cheers Dawid Węgliński
Re: [gentoo-dev] RFC: qt4-r2.eclass - new eclass for Qt-based apps
Dne neděle 29 Listopad 2009 23:11:23 Dawid Węgliński napsal(a): On Sunday 29 November 2009 16:59:10 Ben de Groot wrote: As soon as existing ebuilds in the tree are ported over to qt4-r2, the old qt4.eclass will be removed. As far as i remember we don't remove eclasses. Probably you meant deprecated, but not removed? New eclasses can be removed. But yeah for now it is deprecating. signature.asc Description: This is a digitally signed message part.
