FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-25-2012, 04:09 PM
Alexandre Rostovtsev
 
Default 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}"
}
 
Old 08-25-2012, 05:25 PM
Tomáš Chvátal
 
Default 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
 
Old 08-25-2012, 06:29 PM
Diego Elio Pettenò
 
Default 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/
 
Old 08-25-2012, 09:04 PM
Alexandre Rostovtsev
 
Default 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}"
}
 
Old 08-25-2012, 09:45 PM
Ulrich Mueller
 
Default 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
 
Old 08-26-2012, 06:59 AM
Alexandre Rostovtsev
 
Default 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}"
 
Old 08-26-2012, 07:08 AM
Alexandre Rostovtsev
 
Default 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}"
 
Old 08-26-2012, 07:20 AM
Alexandre Rostovtsev
 
Default 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
 
Old 08-26-2012, 10:32 PM
Duncan
 
Default 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
 
Old 08-26-2012, 10:45 PM
Zac Medico
 
Default 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
 

Thread Tools




All times are GMT. The time now is 04:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org