From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 0062C138010 for ; Mon, 27 Aug 2012 12:21:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 836BCE0511; Mon, 27 Aug 2012 12:20:46 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3AFC9E0084 for ; Mon, 27 Aug 2012 12:20:06 +0000 (UTC) Received: from localhost (pc-193-111-101-190.cm.vtr.net [190.101.111.193]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 24A4133D71A for ; Mon, 27 Aug 2012 12:20:03 +0000 (UTC) Date: Mon, 27 Aug 2012 08:19:56 -0400 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] new vala.eclass Message-ID: <20120827081956.1db290e4@gentoo.org> In-Reply-To: <1346042745.9829.112.camel@rook> References: <1345910966.9829.9.camel@rook> <1345928676.9829.13.camel@rook> <20537.18304.877062.568911@a1i15.kph.uni-mainz.de> <1345964385.9829.80.camel@rook> <503AA725.8020306@gentoo.org> <1346024612.9829.87.camel@rook> <20120826224553.700b29ca@gentoo.org> <1346042745.9829.112.camel@rook> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.11; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: ef82fb69-5ea2-458e-a460-8ca07d56da0a X-Archives-Hash: 4d35ae6d9b6e6fd3fab800efa6108c2d On Mon, 27 Aug 2012 00:45:45 -0400 Alexandre Rostovtsev wrote: > On Sun, 2012-08-26 at 22:45 -0400, Alexis Ballier wrote: > > On Sun, 26 Aug 2012 19:43:32 -0400 > > Alexandre Rostovtsev wrote: > > > The variables that vala_pkg_setup sets are needed only at build > > > time. > > > > so it should be vala_src_prepare / unpack instead ? > > definitely not anything pkg_* imho > > IMHO src_prepare or src_unpack would be misleading because the > function does not modify the package's source and has nothing to do > with unpacking. it creates files as far as i understood the code; the point of vala.eclass is to prepare the environment for building the package, right ? you can probably get a valid point for a src_setup phase in a future eapi, but so far with current eapi, src_prepare seems the best choice > It's not an unusual idiom to set various environment > variables in pkg_setup even if those variables are relevant only at > build time; gnome-extra/zeitgeist and xfce4-vala/xfce4-vala are > typical examples that already export VALAC in their pkg_setup(). lots of bad examples does not make it good :) this is just wasted cpu cycles for binpkgs, moreover these two examples only set a variable and call type -P; the eclass does set a couple more of variables and writes to $T anyway its your call, but given that the eclass is only useful for building it seems bad practices to put its code in a pkg_ phase.