From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OH7mV-0006k5-1N for garchives@archives.gentoo.org; Wed, 26 May 2010 03:59:47 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4C5FFE0C44; Wed, 26 May 2010 03:59:41 +0000 (UTC) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by pigeon.gentoo.org (Postfix) with ESMTP id 408BFE09A1 for ; Wed, 26 May 2010 03:59:16 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so1602695fgg.10 for ; Tue, 25 May 2010 20:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:disposition-notification-to :mime-version:content-type:content-transfer-encoding:message-id; bh=a40GzwQvRzxOCm9SjJ7ULEieKfdbdyvhXzfMX/MyqWA=; b=Yoqa7+98K07zmPsSh9kv4P5M9uVpRaie81E7qqQvRVIdj8rsk+pr5PBDY2iv9WChbf VKU5Dcd8ebm2T83mF4NkMMzVC9QYRI3DlUOi6Z0FuVva/idpdsX4gLiMgg1MWNDH9IU0 P0MCMFKRsLMpZUozPjEzPoB1i2QQFyKM1CJz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to :disposition-notification-to:mime-version:content-type :content-transfer-encoding:message-id; b=jujHMuoAfaJXdqNuprSfNvKAWRO8RSCOUPkVxa1QTGgPibHxVpWM98FV/PGvZHSWkq iyVv+ni77RpzdkQfsGa3istrpadkYaM6HddVf7UnzfX17/D27mePoHx9UF0XzH28ifsS IhHaqhBj5XjJliNV3btNSSmTbjmvRmLK0stlk= Received: by 10.87.64.25 with SMTP id r25mr1358633fgk.20.1274846355564; Tue, 25 May 2010 20:59:15 -0700 (PDT) Received: from lebrodyl.localnet (aafn79.neoplus.adsl.tpnet.pl [83.4.143.79]) by mx.google.com with ESMTPS id d8sm13044353fga.6.2010.05.25.20.59.14 (version=SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 20:59:14 -0700 (PDT) From: Maciej Mrozowski To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [Survey || RFC] autotools-utils.eclass Date: Wed, 26 May 2010 05:59:22 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.32-gentoo-r7; KDE/4.4.3; x86_64; ; ) References: <201005251302.56615.reavertm@gmail.com> <201005251431.34053.vapier@gentoo.org> In-Reply-To: <201005251431.34053.vapier@gentoo.org> 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="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201005260559.22811.reavertm@gmail.com> X-Archives-Salt: 96783f1b-1f74-4856-8bb9-8d3e56ab183b X-Archives-Hash: bd35151f316cd280ee9d525fce72af04 On Tuesday 25 of May 2010 20:31:33 Mike Frysinger wrote: > internal functions should not be documented with the eclass doc comments > (_check_build_dir) Fixed. > reusing a PM variable (ECONF_SOURCE) seems a little iffy I know, initial idea was to use AUTOTOOLS_USE_DIR (analogy to CMAKE_USE_DIR), but then I discovered that I'd need to set ECONF_SOURCE anyway. So to avoid duplicating variables, I opted for ECONF_SOURCE reuse. If it's supposed to have internal meaning and is not part of public API, then I agree should not be used. I see it's explicitly mentioned in PMS though. Waiting for further comments on that matter. > the library handling is incorrect. i dont think you can pass around > --enable- shared all the time without having configure generate warnings > about unknown options. > default to --disable-static when static-libs > doesnt exist is wrong -- that's the opposite of what you should be doing. > ignoring the same issue as the share option i mentioned above. Right. It its safe to assume that when --disable-static/--enable-static is available, then --disable-shared/--enable-shared is available as well? > pushd/popd should have stdout sent to /dev/null, not stderr too Fixed. > the src_install func has the static-libs checks in the incorrect order Fixed. > the src_test func looks like its copying & pasting stuff from the PM. this > really should be kept in the PM without duplicating it everywhere. Unfortunately src_test needs to be called in build dir (which is unknown to PM). Calling default_src_test is the best I could come up with. But what's the most important - is there any interest in having such eclass? I'm only going to add it when it's flexible enough to effectively phase-out eutils/base/autotools/libtool individual uses for fully autotools-controlled buildsystems. Otherwise there's no point in yet another wrapper imho. I was also thinking of integrating parts of src_prepare from virtuoso.eclass into autotools-utils.eclass - it provides basic support for package splitting of well formed (TM) and clean autotools build systems. (example packages are virtuoso-odbc and virtuoso-server). Thanks -- regards MM