Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   RFC: qt4-r2.eclass - new eclass for Qt-based apps (http://www.linux-archive.org/gentoo-development/287686-rfc-qt4-r2-eclass-new-eclass-qt-based-apps.html)

Dominik Kapusta 11-29-2009 10:46 AM

RFC: qt4-r2.eclass - new eclass for Qt-based apps
 
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
# Copyright 2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: qt4-r2.eclass
# @MAINTAINER:
# Ben de Groot <yngwin@gentoo.org>,
# Markos Chandras <hwoarang@gentoo.org>,
# Davide Pesavento <davidepesa@gmail.com>,
# Dominik Kapusta <ayoy@gentoo.org>
# @BLURB: Experimental eclass for Qt4 packages
# @DESCRIPTION:
# This eclass contains various functions that may be useful when
# dealing with packages using Qt4 libraries. Requires EAPI=2.

inherit base eutils multilib toolchain-funcs

export XDG_CONFIG_HOME="${T}"

for x in ${LANGSLONG}; do
IUSE="${IUSE} linguas_${x%_*}"
done

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
}

qt4-r2_src_unpack() {
base_src_unpack

# Fallback to ${WORKDIR}/${MY_P} when ${WORKDIR}/${P} doesn't exist.
# Feel free to re-implement this
if [[ "${S}" == "${WORKDIR}/${P}" && ! -d ${S} && -d ${WORKDIR}/${MY_P} ]]; then
ewarn "Falling back to '${WORKDIR}/${MY_P}'"
S="${WORKDIR}/${MY_P}"
fi
}

# @ECLASS-VARIABLE: PATCHES
# @DESCRIPTION:
# In case you have patches to apply, specify them in PATCHES variable. Make sure
# to specify the full path. This variable is used in src_prepare phase.
# example:
# 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.
# example: DOCS="README AUTHORS"
#
# @ECLASS-VARIABLE: DOCSDIR
# @DESCRIPTION:
# Directory containing documentation. If not specified, ${S} will be used
# instead.
#
# @FUNCTION: qt4-r2_src_prepare
# @DESCRIPTION:
# Default src_prepare function for packages that depend on qt4. If you have to
# override src_prepare in your ebuild, you should call qt4-r2_src_prepare in it,
# otherwise autopatcher will not work!
qt4-r2_src_prepare() {
debug-print-function $FUNCNAME "$@"

base_src_prepare
}

# @FUNCTION: qt4-r2_src_configure
# @DESCRIPTION:
# Default src_configure function for packages that depend on qt4. If you have to
# override src_configure in your ebuild, call qt4-r2_src_configure in it.
qt4-r2_src_configure() {
debug-print-function $FUNCNAME "$@"

local project_file="$(_find_project_file)"

if [[ -n ${project_file} ]]; then
eqmake4 ${project_file}
else
base_src_configure
fi
}

# @FUNCTION: qt4-r2_src_compile
# @DESCRIPTION:
# Default src_compile function for packages that depends on qt4. If you have to
# override src_compile in your ebuild (probably you don't need to), call
# qt4-r2_src_compile in it.
qt4-r2_src_compile() {
debug-print-function $FUNCNAME "$@"

emake || die "emake failed"
}

# @FUNCTION: qt4-r2_src_install
# @DESCRIPTION:
# Default src_install function for qt4-based packages. Installs compiled code,
# documentation (via DOCS variable) and translations (via LANGS and
# LANGSLONG variables).
qt4-r2_src_install() {
debug-print-function $FUNCNAME "$@"

emake INSTALL_ROOT="${D}" install || die "emake install failed"

# install documentation
if [[ -n "${DOCS}" ]]; then
local dir=${DOCSDIR:-${S}}
for doc in ${DOCS}; do
dodoc "${dir}/${doc}" || die "dodoc failed"
done
fi
}

# Internal function, used by eqmake4 and qt4-r2_src_configure
# Look for project files:
# 0 *.pro files found - output null string
# 1 *.pro file found - output its name
# 2 or more *.pro files found - if ${PN}.pro or $(basename ${S}).pro
# are there, output any of them
# Outputs a project file argument used by eqmake4. Sets nullglob locally
# to avoid expanding *.pro as "*.pro" when there are no matching files.
_find_project_file() {
shopt -s nullglob
local pro_files=(*.pro)
shopt -u nullglob
local dir_name="$(basename ${S})"

case ${#pro_files[@]} in
1)
echo "${pro_files[0]}"
;;
*)
for pro_file in "${pro_files[@]}"; do
if [[ "${pro_file}" == "${dir_name}" ||
"${pro_file}" == "${PN}.pro" ]]; then
echo "${pro_file}"
break
fi
done
;;
esac
}

# @FUNCTION: eqmake4
# @USAGE: [project file] [parameters to qmake]
# @DESCRIPTION:
# Wrapper for Qt4's qmake. If project file isn't specified eqmake4 will
# look for it in current directory (${S}, non-recursively). If more than
# one project file is found, the ${PN}.pro is processed, provided that it
# exists. Otherwise eqmake4 fails.
# All the arguments are appended unmodified to qmake command line. For
# recursive build systems, i.e. those based on the subdirs template, you
# should run eqmake4 on the top-level project file only, unless you have
# strong reasons to do things differently. During the building, qmake
# will be automatically re-invoked with the right arguments on every
# directory specified inside the top-level project file by the SUBDIRS
# variable.
eqmake4() {
ebegin "Running qmake"

local qmake_args="$@"

# check if project file was passed as a first argument
# if not, then search for it
local regexp='.*.pro'
if ! [[ "${1}" =~ ${regexp} ]]; then
local project_file="$(_find_project_file)"
if [[ -z "${project_file}" ]]; then
echo
eerror "No project file found in ${S}!"
eerror "This shouldn't happen - please send a bug report to http://bugs.gentoo.org/"
echo
die "eqmake4 failed"
fi
qmake_args="${qmake_args} ${project_file}"
fi

# make sure CONFIG variable is correctly set for both release and debug builds
local CONFIG_ADD="release"
local CONFIG_REMOVE="debug"
if has debug ${IUSE} && use debug; then
CONFIG_ADD="debug"
CONFIG_REMOVE="release"
fi
local awkscript='BEGIN {
printf "### eqmake4 was here ###
" > file;
fixed=0;
}
/^[[:blank:]]*CONFIG[[:blank:]]*[+*]?=/ {
for (i=1; i <= NF; i++) {
if ($i ~ rem || $i ~ /debug_and_release/)
{ $i=add; fixed=1; }
}
}
/^[[:blank:]]*CONFIG[[:blank:]]*-=/ {
for (i=1; i <= NF; i++) {
if ($i ~ add) { $i=rem; fixed=1; }
}
}
{
print >> file;
}
END {
printf "
CONFIG -= debug_and_release %s
", rem >> file;
printf "CONFIG += %s
", add >> file;
print fixed;
}'
local file=
while read file; do
grep -q '^### eqmake4 was here ###$' "${file}" && continue
local retval=$({
rm -f "${file}" || echo "FAILED"
awk -v file="${file}" -- "${awkscript}" add=${CONFIG_ADD} rem=${CONFIG_REMOVE} || echo "FAILED"
} < "${file}")
if [[ ${retval} == 1 ]]; then
einfo " - fixed CONFIG in ${file}"
elif [[ ${retval} != 0 ]]; then
eerror "An error occurred while processing ${file}"
die "eqmake4 failed to process '${file}'"
fi
done < <(find . -type f -name "*.pr[io]" -printf '%P
' 2>/dev/null)

/usr/bin/qmake -makefile -nocache
QTDIR=/usr/$(get_libdir)
QMAKE=/usr/bin/qmake
QMAKE_CC=$(tc-getCC)
QMAKE_CXX=$(tc-getCXX)
QMAKE_LINK=$(tc-getCXX)
QMAKE_CFLAGS_RELEASE="${CFLAGS}"
QMAKE_CFLAGS_DEBUG="${CFLAGS}"
QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"
QMAKE_CXXFLAGS_DEBUG="${CXXFLAGS}"
QMAKE_LFLAGS_RELEASE="${LDFLAGS}"
QMAKE_LFLAGS_DEBUG="${LDFLAGS}"
QMAKE_RPATH=
QMAKE_STRIP=
${qmake_args}

# was qmake successful?
if ! eend $? ; then
echo
eerror "Running qmake has failed! (see above for details)"
eerror "This shouldn't happen - please send a bug report to http://bugs.gentoo.org/"
echo
die "eqmake4 failed"
fi

return 0
}

EXPORT_FUNCTIONS pkg_setup src_unpack src_prepare src_configure src_compile src_install

Thomas Anderson 11-29-2009 12:54 PM

RFC: qt4-r2.eclass - new eclass for Qt-based apps
 
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
--
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

Dominik Kapusta 11-29-2009 01:29 PM

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

Markos Chandras 11-29-2009 01:45 PM

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

Ben de Groot 11-29-2009 02:59 PM

RFC: qt4-r2.eclass - new eclass for Qt-based apps
 
2009/11/29 Thomas Anderson <tanderson@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)
__________________________________________________ ____

Dawid Węgliński 11-29-2009 09:11 PM

RFC: qt4-r2.eclass - new eclass for Qt-based apps
 
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?

--
Cheers
Dawid Węgliński

Tomáš Chvátal 11-29-2009 09:14 PM

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.

Ben de Groot 11-29-2009 10:19 PM

RFC: qt4-r2.eclass - new eclass for Qt-based apps
 
2009/11/29 Dawid Węgliński <cla@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)
__________________________________________________ ____

Dawid Węgliński 11-29-2009 10:34 PM

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 <cla@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

Dominik Kapusta 12-03-2009 05:44 PM

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
# Copyright 2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: qt4-r2.eclass
# @MAINTAINER:
# Ben de Groot <yngwin@gentoo.org>,
# Markos Chandras <hwoarang@gentoo.org>,
# Davide Pesavento <davidepesa@gmail.com>,
# Dominik Kapusta <ayoy@gentoo.org>
# @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}"

# @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

# @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() {
debug-print-function $FUNCNAME "$@"

# Fallback to ${WORKDIR}/${MY_P} when ${WORKDIR}/${P} doesn't exist.
# Feel free to re-implement this
if [[ "${S}" == "${WORKDIR}/${P}" && ! -d ${S} && -d ${WORKDIR}/${MY_P} ]]; then
ewarn "Falling back to '${WORKDIR}/${MY_P}'"
S="${WORKDIR}/${MY_P}"
fi

base_src_unpack "$@"
}

# @ECLASS-VARIABLE: PATCHES
# @DESCRIPTION:
# In case you have patches to apply, specify them in PATCHES variable. Make sure
# to specify the full path. This variable is used in src_prepare phase.
# example:
# PATCHES=( "${FILESDIR}"/mypatch.patch
# "${FILESDIR}"/mypatch2.patch )
#
# @FUNCTION: qt4-r2_src_prepare
# @DESCRIPTION:
# Default src_prepare function for packages that depend on qt4. If you have to
# override src_prepare in your ebuild, you should call qt4-r2_src_prepare in it,
# otherwise autopatcher will not work!
qt4-r2_src_prepare() {
debug-print-function $FUNCNAME "$@"

base_src_prepare "$@"
}

# @FUNCTION: qt4-r2_src_configure
# @DESCRIPTION:
# Default src_configure function for packages that depend on qt4. If you have to
# override src_configure in your ebuild, call qt4-r2_src_configure in it.
qt4-r2_src_configure() {
debug-print-function $FUNCNAME "$@"

local project_file="$(_find_project_file)"

if [[ -n ${project_file} ]]; then
eqmake4 ${project_file}
else
base_src_configure "$@"
fi
}

# @FUNCTION: qt4-r2_src_compile
# @DESCRIPTION:
# Default src_compile function for packages that depend on qt4. If you have to
# override src_compile in your ebuild (probably you don't need to), call
# qt4-r2_src_compile in it.
qt4-r2_src_compile() {
debug-print-function $FUNCNAME "$@"

base_src_compile "$@"
}

# @ECLASS-VARIABLE: DOCS
# @DESCRIPTION:
# Use this variable if you want to install any documentation.
# example: DOCS="README AUTHORS"
#
# @ECLASS-VARIABLE: DOCSDIR
# @DESCRIPTION:
# Directory containing documentation. If not specified, ${S} will be used
# instead.
#
# @FUNCTION: qt4-r2_src_install
# @DESCRIPTION:
# Default src_install function for qt4-based packages. Installs compiled code,
# documentation (via DOCS variable) and translations (via LANGS and
# LANGSLONG variables).
qt4-r2_src_install() {
debug-print-function $FUNCNAME "$@"

emake INSTALL_ROOT="${D}" DESTDIR="${D}" install || die "emake install failed"

# install documentation
if [[ -n "${DOCS}" ]]; then
local dir=${DOCSDIR:-${S}}
for doc in ${DOCS}; do
dodoc "${dir}/${doc}" || die "dodoc failed"
done
fi
}

# Internal function, used by eqmake4 and qt4-r2_src_configure
# Look for project files:
# 0 *.pro files found - output null string
# 1 *.pro file found - output its name
# 2 or more *.pro files found - if ${PN}.pro or $(basename ${S}).pro
# are there, output any of them
# Outputs a project file argument used by eqmake4. Sets nullglob locally
# to avoid expanding *.pro as "*.pro" when there are no matching files.
_find_project_file() {
shopt -s nullglob
local pro_files=(*.pro)
shopt -u nullglob
local dir_name="$(basename ${S})"

case ${#pro_files[@]} in
1)
echo "${pro_files[0]}"
;;
*)
for pro_file in "${pro_files[@]}"; do
if [[ "${pro_file}" == "${dir_name}" ||
"${pro_file}" == "${PN}.pro" ]]; then
echo "${pro_file}"
break
fi
done
;;
esac
}

# @FUNCTION: eqmake4
# @USAGE: [project file] [parameters to qmake]
# @DESCRIPTION:
# Wrapper for Qt4's qmake. If project file isn't specified eqmake4 will
# look for it in current directory (${S}, non-recursively). If more than
# one project file is found, the ${PN}.pro is processed, provided that it
# exists. Otherwise eqmake4 fails.
# All the arguments are appended unmodified to qmake command line. For
# recursive build systems, i.e. those based on the subdirs template, you
# should run eqmake4 on the top-level project file only, unless you have
# strong reasons to do things differently. During the building, qmake
# will be automatically re-invoked with the right arguments on every
# directory specified inside the top-level project file by the SUBDIRS
# variable.
eqmake4() {
ebegin "Running qmake"

local qmake_args="$@"

# check if project file was passed as a first argument
# if not, then search for it
local regexp='.*.pro'
if ! [[ "${1}" =~ ${regexp} ]]; then
local project_file="$(_find_project_file)"
if [[ -z "${project_file}" ]]; then
echo
eerror "No project file found in ${S}!"
eerror "This shouldn't happen - please send a bug report to http://bugs.gentoo.org/"
echo
die "eqmake4 failed"
fi
qmake_args="${qmake_args} ${project_file}"
fi

# make sure CONFIG variable is correctly set for both release and debug builds
local CONFIG_ADD="release"
local CONFIG_REMOVE="debug"
if has debug ${IUSE} && use debug; then
CONFIG_ADD="debug"
CONFIG_REMOVE="release"
fi
local awkscript='BEGIN {
printf "### eqmake4 was here ###
" > file;
fixed=0;
}
/^[[:blank:]]*CONFIG[[:blank:]]*[+*]?=/ {
for (i=1; i <= NF; i++) {
if ($i ~ rem || $i ~ /debug_and_release/)
{ $i=add; fixed=1; }
}
}
/^[[:blank:]]*CONFIG[[:blank:]]*-=/ {
for (i=1; i <= NF; i++) {
if ($i ~ add) { $i=rem; fixed=1; }
}
}
{
print >> file;
}
END {
printf "
CONFIG -= debug_and_release %s
", rem >> file;
printf "CONFIG += %s
", add >> file;
print fixed;
}'
local file=
while read file; do
grep -q '^### eqmake4 was here ###$' "${file}" && continue
local retval=$({
rm -f "${file}" || echo "FAILED"
awk -v file="${file}" -- "${awkscript}" add=${CONFIG_ADD} rem=${CONFIG_REMOVE} || echo "FAILED"
} < "${file}")
if [[ ${retval} == 1 ]]; then
einfo " - fixed CONFIG in ${file}"
elif [[ ${retval} != 0 ]]; then
eerror "An error occurred while processing ${file}"
die "eqmake4 failed to process '${file}'"
fi
done < <(find . -type f -name "*.pr[io]" -printf '%P
' 2>/dev/null)

/usr/bin/qmake -makefile -nocache
QTDIR=/usr/$(get_libdir)
QMAKE=/usr/bin/qmake
QMAKE_CC=$(tc-getCC)
QMAKE_CXX=$(tc-getCXX)
QMAKE_LINK=$(tc-getCXX)
QMAKE_CFLAGS_RELEASE="${CFLAGS}"
QMAKE_CFLAGS_DEBUG="${CFLAGS}"
QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"
QMAKE_CXXFLAGS_DEBUG="${CXXFLAGS}"
QMAKE_LFLAGS_RELEASE="${LDFLAGS}"
QMAKE_LFLAGS_DEBUG="${LDFLAGS}"
QMAKE_RPATH=
QMAKE_STRIP=
${qmake_args}

# was qmake successful?
if ! eend $? ; then
echo
eerror "Running qmake has failed! (see above for details)"
eerror "This shouldn't happen - please send a bug report to http://bugs.gentoo.org/"
echo
die "eqmake4 failed"
fi

return 0
}

EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install


All times are GMT. The time now is 02:59 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.