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 67A34198005 for ; Sun, 24 Feb 2013 15:52:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BD90CE06C0; Sun, 24 Feb 2013 15:52:50 +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 C10A8E0453 for ; Sun, 24 Feb 2013 15:52:49 +0000 (UTC) Received: from pomiocik.lan (unknown [213.195.173.220]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 28E3B33DC7D; Sun, 24 Feb 2013 15:52:46 +0000 (UTC) Date: Sun, 24 Feb 2013 16:53:02 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Cc: pacho@gentoo.org Subject: Re: [gentoo-dev] New eclass: autotools-multilib-minimal Message-ID: <20130224165302.7470cb1b@pomiocik.lan> In-Reply-To: <1361718738.20067.54.camel@belkin4> References: <51296027.705@gentoo.org> <51299593.1010902@gentoo.org> <20130224155715.428b0493@pomiocik.lan> <1361718738.20067.54.camel@belkin4> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; 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: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/lkQV_gW2=LUrhF79vsbnAKe"; protocol="application/pgp-signature" X-Archives-Salt: 5891802c-be10-41d7-97e0-0dfc3567c0de X-Archives-Hash: de29d71c7e73be3fa541461e10803d7c --Sig_/lkQV_gW2=LUrhF79vsbnAKe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 24 Feb 2013 16:12:18 +0100 Pacho Ramos wrote: > El dom, 24-02-2013 a las 15:57 +0100, Micha=C5=82 G=C3=B3rny escribi=C3= =B3: > [...] > > > d) the previous point will also allow to convert go-mono.eclass packa= ges > > > without introducing yet another eclass for that > >=20 > > So you're introducing a hacky eclass just because you're too lazy to > > convert go-mono packages properly and too impatient to let others do > > the work properly for you? >=20 > Would be nice to know what autotools-utils.eclass is doing differently > that is showing this problem with go-mono.eclass packages :/ I already told that I'm going to look at this but I have too much work to do right now so it's going to take a longer while. > Only one question, what is the reason for us having base.eclass and > autotools-utils.eclass? I think that base.eclass is silently intended for removal at some point in the future. While we're here, we should probably mark it deprecated. autotools-utils does a bit more -- especially by using out-of-source builds. The major reason to use autotools-utils so far was to support those builds. Believe me or not, the day I took over the maintenance of it I seen the opportunity to use out-of-source builds for multilib. Today, both python-r1 & multilib-build were specifically designed to allow using out-of-source builds with minimal effort. > 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: - 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. - 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. - adding libtool args for shared/static libs if IUSE=3Dstatic-libs -- which I wanted to remove but people considered it useful. > 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=20 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. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/lkQV_gW2=LUrhF79vsbnAKe Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQJ8BAEBCgBmBQJRKjdfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKB+MQAOG5CnBoYR+ANiTuEM5ZRFs9 cdlsJTMBmUa6znHrSFQ2sNmzouji5th8W3MJNAt+b6TqXr0A7Y7CxsuB1uSvYnOF X/hNY9KIT0NlNuba6l1zKZYJqu6FW5Ake/g+SmXFH5alK8ljpJLbH3WIW0FSY9Jr co9/Da3N4OTDhI9D2Ceaz4l//ZAaKyt4fZ2QOS1M2BopjzU63vvo5TDDEQueEYkt 0ddNKGOS1UuAyD77Li1Rd7IM3pJSkw+tIo0PmzTV68sAiVy5+68vm6UO8D08A5XW v28txBKNQfDQN99mvKtSdw3G++FXV5vInS8zQEriLqYL1Kd/0M6jcDyGEIR7WcRU zTt5Yg6tk5t8nhF0XEphpxO2dAr47Rb5XeF0WCtMaDCUZnQnqZ08HjMpCsGJB7hB UIbcVyh4pZ7Y3Th2JJG9BZIZFxPSrJeUBU1DS60Z2jBU4aei2/40jO14goztNp55 /PTg23JobT5O9WLDU4EGZL/CPV+qZ2tttQ7H409COelLSZpzrJO7rwOsOwd9CkuW E1Bv8uuaMOq6FRJG2NDq6PVpZrL/k5dWAe5FKZWSxFFESBcRKzOH9NLF6c98C9FM EVpjuLojNSZml+EDrfRPMYE2gHVUVAlU/H1w8uD9binaXjkE2Y8eI7BgBHdjms+f QABqY975bXfjh09mSGYV =S+dE -----END PGP SIGNATURE----- --Sig_/lkQV_gW2=LUrhF79vsbnAKe--