Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   new vala.eclass (http://www.linux-archive.org/gentoo-development/697648-new-vala-eclass.html)

Alexandre Rostovtsev 08-25-2012 04:09 PM

new vala.eclass
 
Here's a proposed new eclass to make it less painful to build vala
bindings in the new, vala-0.18.x, vapigen.m4-using era. See
https://bugzilla.gnome.org/show_bug.cgi?id=682202 for why messing around
with PKG_CONFIG_PATH is unfortunately needed for vapigen.m4-using
packages from gnome-3.6 such as librsvg-2.36.2, networkmanager-0.9.6.0,
libsecret-0.9.x, libgnome-keyring-3.6.x, accountsservice-0.6.24, etc.


# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: vala.eclass
# @MAINTAINER:
# gnome@gentoo.org
# @AUTHOR:
# Alexandre Rostovtsev <tetromino@gentoo.org>
# @BLURB: Sets up the environment for using a specific version of vala.
# @DESCRIPTION:
# This eclass sets up commonly used environment variables for using a specific
# version of dev-lang/vala to configure and build a package. It is needed for
# packages whose build systems assume the existence of certain unversioned vala
# executables, pkgconfig files, etc., which Gentoo does not provide.
#
# This eclass provides one phase function: pkg_setup.

inherit multilib

case "${EAPI:-0}" in
0|1|2)
die "EAPI=${EAPI} is not supported"
;;
*)
EXPORT_FUNCTIONS pkg_setup
;;
esac

# @ECLASS-VARIABLE: VALA_API_VERSION
# @DEFAULT_UNSET
# @DESCRIPTION:
# Vala API version (e.g. 0.16).

# @FUNCTION: vala_pkg_setup
# @DESCRIPTION:
# Sets up the environment variables and pkgconfig files for $VALA_API_VERSION.
vala_pkg_setup() {
if [[ -z "${VALA_API_VERSION}" ]]; then
die "VALA_API_VERSION not set"
fi

export VALAC=$(type -P valac-${VALA_API_VERSION})
export VALA=$(type -P vala-${VALA_API_VERSION})
export VALA_GEN_INTROSPECT=$(type -P vala-gen-introspect-${VALA_API_VERSION})
export VAPIGEN="$(type -P vapigen-${VALA_API_VERSION})"
export VAPIGEN_MAKEFILE="${EPREFIX}/usr/share/vala-${VALA_API_VERSION}/Makefile.vapigen"
export VAPIGEN_VAPIDIR="${EPREFIX}/usr/share/vala/vapi"

if ! [[ -d "${T}/pkgconfig" ]]; then
mkdir "${T}/pkgconfig" || die "mkdir failed"
fi
local p
for p in libvala vapigen; do
local d
for d in "${EPREFIX}/usr/$(get_libdir)/pkgconfig" "${EPREFIX}/usr/share/pkgconfig"; do
if [[ -e "${d}/${p}-${VALA_API_VERSION}.pc" ]]; then
ln -s "${d}/${p}-${VALA_API_VERSION}.pc" "${T}/pkgconfig/${p}.pc" || die "ln failed"
break
fi
done
done
: ${PKG_CONFIG_PATH:="${EPREFIX}/usr/$(get_libdir)/pkgconfig:${EPREFIX}/usr/share/pkgconfig"}
export PKG_CONFIG_PATH="${T}/pkgconfig:${PKG_CONFIG_PATH}"
}

Tomáš Chvátal 08-25-2012 05:25 PM

new vala.eclass
 
2012/8/25 Alexandre Rostovtsev <tetromino@gentoo.org>:
Hi man,

*snip*
>
> case "${EAPI:-0}" in
> 0|1|2)
> die "EAPI=${EAPI} is not supported"
> ;;
> *)
> EXPORT_FUNCTIONS pkg_setup
> ;;
> esac

Any reson for not supporting ALL known eapis?

*snip*
> if [[ -z "${VALA_API_VERSION}" ]]; then
> die "VALA_API_VERSION not set"
> fi
You can use the && instead of conditional as you have longer lines in
the file anyway

*snip*
> if ! [[ -d "${T}/pkgconfig" ]]; then
> mkdir "${T}/pkgconfig" || die "mkdir failed"
> fi
Same as above

*snip*
> local p
You should put the var defs on the top, I know this aint ansi C but i
found that we tend to loose the variable declarations in long run
otherwise.

Cheers

Tom

Diego Elio Pettenò 08-25-2012 06:29 PM

new vala.eclass
 
On 25/08/2012 10:25, Tomáš Chvátal wrote:
>> > if ! [[ -d "${T}/pkgconfig" ]]; then
>> > mkdir "${T}/pkgconfig" || die "mkdir failed"
>> > fi
> Same as above

Even better use mkdir -p.

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Alexandre Rostovtsev 08-25-2012 09:04 PM

new vala.eclass
 
Updated version, incorporating suggestions by Tomáš and Diego, and
fixing VAPIGEN_MAKEFILE to work with dev-lang/vala-common.

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: vala.eclass
# @MAINTAINER:
# gnome@gentoo.org
# @AUTHOR:
# Alexandre Rostovtsev <tetromino@gentoo.org>
# @BLURB: Sets up the environment for using a specific version of vala.
# @DESCRIPTION:
# This eclass sets up commonly used environment variables for using a specific
# version of dev-lang/vala to configure and build a package. It is needed for
# packages whose build systems assume the existence of certain unversioned vala
# executables, pkgconfig files, etc., which Gentoo does not provide.
#
# This eclass provides one phase function: pkg_setup.

inherit multilib

EXPORT_FUNCTIONS pkg_setup

# @ECLASS-VARIABLE: VALA_API_VERSION
# @DEFAULT_UNSET
# @DESCRIPTION:
# Vala API version (e.g. 0.16).

# @FUNCTION: vala_pkg_setup
# @DESCRIPTION:
# Sets up the environment variables and pkgconfig files for $VALA_API_VERSION.
vala_pkg_setup() {
local p d

[[ -n "${VALA_API_VERSION}" ]] || die "VALA_API_VERSION not set"

export VALAC=$(type -P valac-${VALA_API_VERSION})
export VALA=$(type -P vala-${VALA_API_VERSION})
export VALA_GEN_INTROSPECT=$(type -P vala-gen-introspect-${VALA_API_VERSION})
export VAPIGEN="$(type -P vapigen-${VALA_API_VERSION})"
export VAPIGEN_MAKEFILE="${EPREFIX}/usr/share/vala/Makefile.vapigen"
export VAPIGEN_VAPIDIR="${EPREFIX}/usr/share/vala/vapi"

mkdir -p "${T}/pkgconfig" || die "mkdir failed"
for p in libvala vapigen; do
for d in "${EPREFIX}/usr/$(get_libdir)/pkgconfig" "${EPREFIX}/usr/share/pkgconfig"; do
if [[ -e "${d}/${p}-${VALA_API_VERSION}.pc" ]]; then
ln -s "${d}/${p}-${VALA_API_VERSION}.pc" "${T}/pkgconfig/${p}.pc" || die "ln failed"
break
fi
done
done
: ${PKG_CONFIG_PATH:="${EPREFIX}/usr/$(get_libdir)/pkgconfig:${EPREFIX}/usr/share/pkgconfig"}
export PKG_CONFIG_PATH="${T}/pkgconfig:${PKG_CONFIG_PATH}"
}

Ulrich Mueller 08-25-2012 09:45 PM

new vala.eclass
 
>>>>> On Sat, 25 Aug 2012, Alexandre Rostovtsev wrote:

> export VALAC=$(type -P valac-${VALA_API_VERSION})
> export VALA=$(type -P vala-${VALA_API_VERSION})
> export VALA_GEN_INTROSPECT=$(type -P vala-gen-introspect-${VALA_API_VERSION})
> export VAPIGEN="$(type -P vapigen-${VALA_API_VERSION})"

Is it guaranteed that these commands are present at pkg_setup time?

Ulrich

Alexandre Rostovtsev 08-26-2012 06:59 AM

new vala.eclass
 
On Sat, 2012-08-25 at 23:45 +0200, Ulrich Mueller wrote:
> >>>>> On Sat, 25 Aug 2012, Alexandre Rostovtsev wrote:
>
> > export VALAC=$(type -P valac-${VALA_API_VERSION})
> > export VALA=$(type -P vala-${VALA_API_VERSION})
> > export VALA_GEN_INTROSPECT=$(type -P vala-gen-introspect-${VALA_API_VERSION})
> > export VAPIGEN="$(type -P vapigen-${VALA_API_VERSION})"
>
> Is it guaranteed that these commands are present at pkg_setup time?

I am assuming that the ebuild writer has added the correct vala
dependency to DEPEND. Maybe something like this:

VALA_API_VERSION=0.16
DEPEND="vala? ( >=dev-lang/vala-0.16.1:${VALA_API_VERSION}[vapigen] )"

In which case, the vala commands that are pulled in via DEPEND will be
(unless I am completely wrong about how pkg_config works) available
during pkg_config.

Commands that are not pulled in via DEPEND of course might not be
available, in which case VALAC or VAPIGEN etc. would be set to the empty
string by vala_pkg_config.

For all vala-using build systems that I have seen, this should not break
anything.

However, for a cleaner and safer environment, I could do the following:

local path

path=$(type -P valac-${VALA_API_VERSION})
[[ -n "${path}" ]] && VALAC="${path}"

path=$(type -P vala-${VALA_API_VERSION})
[[ -n "${path}" ]] && VALA="${path}"

path=$(type -P vala-gen-introspect-${VALA_API_VERSION})
[[ -n "${path}" ]] && VALA_GEN_INTROSPECT="${path}"

path=$(type -P vapigen-${VALA_API_VERSION})
[[ -n "${path}" ]] && VAPIGEN="${path}"

Alexandre Rostovtsev 08-26-2012 07:08 AM

new vala.eclass
 
On Sun, 2012-08-26 at 02:59 -0400, Alexandre Rostovtsev wrote:
> path=$(type -P valac-${VALA_API_VERSION})
> [[ -n "${path}" ]] && VALAC="${path}"
>
> path=$(type -P vala-${VALA_API_VERSION})
> [[ -n "${path}" ]] && VALA="${path}"
>
> path=$(type -P vala-gen-introspect-${VALA_API_VERSION})
> [[ -n "${path}" ]] && VALA_GEN_INTROSPECT="${path}"
>
> path=$(type -P vapigen-${VALA_API_VERSION})
> [[ -n "${path}" ]] && VAPIGEN="${path}"

Sorry, meant

path=$(type -P valac-${VALA_API_VERSION})
[[ -n "${path}" ]] && export VALAC="${path}"

path=$(type -P vala-${VALA_API_VERSION})
[[ -n "${path}" ]] && export VALA="${path}"

path=$(type -P vala-gen-introspect-${VALA_API_VERSION})
[[ -n "${path}" ]] && export VALA_GEN_INTROSPECT="${path}"

path=$(type -P vapigen-${VALA_API_VERSION})
[[ -n "${path}" ]] && export VAPIGEN="${path}"

Alexandre Rostovtsev 08-26-2012 07:20 AM

new vala.eclass
 
On Sun, 2012-08-26 at 02:59 -0400, Alexandre Rostovtsev wrote:
> In which case, the vala commands that are pulled in via DEPEND will be
> (unless I am completely wrong about how pkg_config works) available
> during pkg_config.
>
> Commands that are not pulled in via DEPEND of course might not be
> available, in which case VALAC or VAPIGEN etc. would be set to the empty
> string by vala_pkg_config.

s/pkg_config/pkg_setup/g

Duncan 08-26-2012 10:32 PM

new vala.eclass
 
Alexandre Rostovtsev posted on Sat, 25 Aug 2012 17:04:36 -0400 as
excerpted:

> [[ -n "${VALA_API_VERSION}" ]] || die "VALA_API_VERSION not set"

It's just style, but...

1) [[ ]] manages non-word characters (whitespace, etc) hidden behind
variables, so quotes are only necessary if they appear in string-
literals, not the case here. I know eliminating the quotes is gentoo
policy as I've seen it suggested many times before.

2) Gentoo policy regarding implied -n? I know gentoo policy prefers {}
cuddled varnames to make the varname explicit, but does it prefer
explicit -n as well, since that's implicit test behavior and thus does
not need to be explicitly specified?

To my way of thinking [[ ${var} ]] is even clearer than [[ -n ${var} ]]
since there's only one way to interpret the former and I have to
correctly parse the -n (as opposed to -any-other-letter) given the
latter. They're even listed together in bash's "help test" output, so
are considered to have identical behavior to the point of being listed
together by bash itself.

Incorporating both suggestions:

[[ ${VALA_API_VERSION} ]] || die "VALA_API_VERSION not set"

But regardless of #2, definitely eliminate the quotes inside the [[ ]],
as I've seen that suggested numerous times in other cases. The better
quote handling regarding variables is in fact one of the reasons the
[[ ]] form is preferred to the POSIX compliant [ ] form.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Zac Medico 08-26-2012 10:45 PM

new vala.eclass
 
On 08/25/2012 11:59 PM, Alexandre Rostovtsev wrote:
> On Sat, 2012-08-25 at 23:45 +0200, Ulrich Mueller wrote:
>>>>>>> On Sat, 25 Aug 2012, Alexandre Rostovtsev wrote:
>>
>>> export VALAC=$(type -P valac-${VALA_API_VERSION})
>>> export VALA=$(type -P vala-${VALA_API_VERSION})
>>> export VALA_GEN_INTROSPECT=$(type -P vala-gen-introspect-${VALA_API_VERSION})
>>> export VAPIGEN="$(type -P vapigen-${VALA_API_VERSION})"
>>
>> Is it guaranteed that these commands are present at pkg_setup time?
>
> I am assuming that the ebuild writer has added the correct vala
> dependency to DEPEND. Maybe something like this:

Note that pkg_setup is called for binary packages too, which means that
DEPEND may not necessarily be installed. In EAPI 4 you can check the
MERGE_TYPE variable which can have a value of binary, source, orbuildonly.
--
Thanks,
Zac


All times are GMT. The time now is 11:35 PM.

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