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 1OJvwO-0006VJ-IE for garchives@archives.gentoo.org; Wed, 02 Jun 2010 21:57:36 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8752BE0C1F; Wed, 2 Jun 2010 21:57:30 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1307EE0B70 for ; Wed, 2 Jun 2010 21:57:10 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id A24811B41CE; Wed, 2 Jun 2010 21:57:09 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] toolchain-funcs.eclass: functions to call compiler Date: Wed, 2 Jun 2010 17:56:38 -0400 User-Agent: KMail/1.13.1 (Linux/2.6.34; KDE/4.4.3; x86_64; ; ) Cc: =?utf-8?q?Micha=C5=82_G=C3=B3rny?= References: <20100531211246.64181dab@pomiocik.lan> <201006020316.13155.vapier@gentoo.org> <20100602151700.6e367219@pomiocik.lan> In-Reply-To: <20100602151700.6e367219@pomiocik.lan> 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; boundary="nextPart23637325.WXeGWUbUy7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201006021756.39934.vapier@gentoo.org> X-Archives-Salt: c7175be7-2d4e-46d7-bcd5-a15bf6f47fb2 X-Archives-Hash: cd913df9ae5a6ef7cabe0278090c6b56 --nextPart23637325.WXeGWUbUy7 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wednesday, June 02, 2010 09:17:00 Micha=C5=82 G=C3=B3rny wrote: > On Wed, 2 Jun 2010 03:16:12 -0400 Mike Frysinger wrote: > > On Monday, May 31, 2010 15:12:46 Micha=C5=82 G=C3=B3rny wrote: > > > There are many simple applications which come without neither a > > > sophisticated build system or even a tiny Makefile. In some cases, > > > such applications aren't even packages as tarball -- a single, > > > compressed source file is published instead. > > >=20 > > > In case of these applications, ebuilds inherit > > > toolchain-funcs.eclass to retrieve compiler information > > > (tc-getCC/tc-getCXX) and call compiler manually, passing > > > appropriate flags. > >=20 > > use emake then and leverage make's implicit rules. >=20 > The implicit make rules are less universal and -- in the fact -- pretty > poor. They're strictly make-dependant, which reduces the amount of > control over their behavior. In my opinion, if we should ever use such > behavior, it should be rather technical implementation of the functions > I'm proposing instead of inline use. ebuilds requires GNU make which means the implicit rules are "universal". = not=20 that i really know what you're talking about. the rules are also clearly=20 documented and support all the proper flags we currently support. > POSIX (man 1p make) defines only simple rule for C files: > $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< POSIX rules are irrelevant. read the GNU make documentation. > Namely, advantages of my solution over directly calling emake is: > 1) direct control over how compiler will be called =3D=3D better > portability, irrelevant. this is like saying we should use POSIX shell code instead of= =20 bash because it's "better portability". we use the tools that are required= by=20 the ebuild system and that means GNU make. > 2) possibility of using any output filename (with emake we'd have to > rename), the -o location is irrelevant in the compile line, and most packages name t= he=20 source file the same as the output, so not that big of a deal > 3) possibility of clearly using multiple input files, yep > 4) possibility of using any input file suffix, perhaps, but very few packages are stupid enough to name a file moocow.txt= =20 when it's really a C file > 5) clear separation between user-specified and ebuild-specified flags > (yes, I'm aware of '+=3D' GNU make extension). hard to sat it's irrelevant > And after all, starting a make jobserver for a single compiler process > doesn't seem really useful. and serializing multiple files is worse > > sys-apps/unscd is a pretty straight forward example. >=20 > In my opinion it's rather a poor example. It's the simplest case > possible -- single file, no additional flags, no libs. and there are many like it btw, toolchain-funcs is not really the best place to add this. it's an ecl= ass=20 for querying, not compiling. better to start a new one. =2Dmike --nextPart23637325.WXeGWUbUy7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAABAgAGBQJMBtOXAAoJEEFjO5/oN/WBrLYP/iF3ww5LWeZhtIs0hj1VlBql WLEBMr3Axu1OXIApLc7js+J/hmY7O9CjG2w8lH3nx27gJ/Tq6DCey74Ufzi6PjpB w9bDgZlHUBqQm8kb8aNGCLWuTuHhoY7cHI3BCTYHKZkfV9taj+LDRlybL4ZJ7ZlC +P3BCwxTh99ZM1wflXOO+tnSulNpS1l33DvKokCY/spF3k+MbEScmawwOL+qla3E 3jIsusCB9t6wFvoYItvF8gvKjnHu+2/EGJoc3Uwvwtj1CGug7YRVx3QAVVo0Q9wv foQQs9RsX/whfqlFzYYhf//ZphJYzH8NY0py1MtFgR0VSnsrl0w11MR8IRkeTt5N jgZK9ghRrRD2qWHi6/MqOskLSbxOByB1rI6L2layE805YsCJR+Wv/iMz/Ap3Ehw4 nGSNbntP4MuqU+tZYnOD4rM3gLs1WPVa8RIuZHdzDCd37cFrlHTRFOqda+lEkZFJ /wOrfTTWxyLcsOSlluHwzyplZt/CiNAa3bfc9+S0i5z/3ZOr+LKB+xyPlzQ07xln h+crWP1cEcJ7M4QxPMNdFztC4knD2LLJD5RBUsidDTpZq0aJD0rubPNnYbs9HWRY BofwFNgnzVl+efFX8S3DoCeTApdIQ+LlLQbOMLKeWNKTFBMykZb03/1rZfEziqIt ZNdSFRfYph9qLr/AVzbz =kLDb -----END PGP SIGNATURE----- --nextPart23637325.WXeGWUbUy7--