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 A7E50198005 for ; Sun, 24 Feb 2013 16:59:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BAE28E0763; Sun, 24 Feb 2013 16:59:13 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CCBF2E0747 for ; Sun, 24 Feb 2013 16:59:12 +0000 (UTC) Received: from [10.186.203.210] (212-226-59-231-nat.elisa-mobile.fi [212.226.59.231]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ssuominen) by smtp.gentoo.org (Postfix) with ESMTPSA id 37AEC33DCD7 for ; Sun, 24 Feb 2013 16:59:10 +0000 (UTC) Message-ID: <512A46A0.6050007@gentoo.org> Date: Sun, 24 Feb 2013 18:58:08 +0200 From: Samuli Suominen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] New eclass: autotools-multilib-minimal References: <51296027.705@gentoo.org> <51299593.1010902@gentoo.org> <20130224155715.428b0493@pomiocik.lan> <1361718738.20067.54.camel@belkin4> <20130224165302.7470cb1b@pomiocik.lan> In-Reply-To: <20130224165302.7470cb1b@pomiocik.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 9a85b565-7e08-4e1a-bc84-f2ccfaed4858 X-Archives-Hash: 4df2eb35abf53984dac0303cb90c4d3f On 24/02/13 17:53, Michał Górny wrote: >> I still try to use plain ebuilds without >> inheritting autotools-utils.eclass as I usually don't need it, probably >> others do the same and refuse to have to inherit it only for multilib >> support :/ How do you plan to solve this problem? > > You generally have two options on doing multilib builds: either using > out-of-source builds or in-source builds. If you decide on the latter, > you unnecessarily waste users' time and disk space to create two more > copies of sources. I don't think we should go this way. > > If you decide on out-of-source builds, you basically need proper > src_{configure,compile,test,install} and that's what autotools-utils > does. Plus: > > - patch applying and autoreconf in src_prepare() -- which are > completely optional, you are free to write your own src_prepare(). > If you wanted to apply patches by hand, you'd need to write > src_prepare() anyway. It's that "Plus" part that is my problem with autotools-multilib.eclass currently, it adds EXPORT_FUNCTIONS of src_prepare() from autotools-utils.eclass which is irrelevant to the autotools-multilib.eclass adds just another eclass/phase function to worry about for inherit order > > - prune_libtool_files in src_install() which most people want to do > anyway, so that doesn't hurt -- and the pkg-config dep is going to > be removed, by the patch I sent already. but lacks a way to pass arguments to prune_libtool_files, like --all, since prune_libtool_files isn't that smart it gets it right everytime i propably prefer to stick to manually calling it with or without --all and well, this is not related to the multilib conversion so it shouldn't be executed anyway > - adding libtool args for shared/static libs if IUSE=static-libs -- > which I wanted to remove but people considered it useful. if it's not related to the multilib conversion, it shouldn't be executed... > >> I would also like to hear why that people refuses to use >> autotools-utils.eclass... because I don't have a strong opinion on this >> topic > > Well, the major argument was similar to yours -- why we should use > an eclass if default PMS functions work. But in the multilib case, they > do not work by design anymore. > src_prepare() seems to be adequate from PMS for the multilib conversion