From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Fo0qK-0000GI-1T for garchives@archives.gentoo.org; Wed, 07 Jun 2006 16:25:16 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k57GNRiv027694; Wed, 7 Jun 2006 16:23:27 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k57GKK8K027759 for ; Wed, 7 Jun 2006 16:20:21 GMT Received: from home.wh0rd.org (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 1188664DDE for ; Wed, 7 Jun 2006 16:20:18 +0000 (UTC) Received: (qmail 31569 invoked from network); 7 Jun 2006 12:17:23 -0400 Received: from unknown (HELO vapier) (192.168.0.2) by 192.168.0.1 with SMTP; 7 Jun 2006 12:17:23 -0400 From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1 Date: Wed, 7 Jun 2006 12:24:10 -0400 User-Agent: KMail/1.9.1 References: <20060607151325.GA27076@nightcrawler> In-Reply-To: <20060607151325.GA27076@nightcrawler> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5689896.P9onPJ0SQR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606071224.11042.vapier@gentoo.org> X-Archives-Salt: b8b61ab1-0686-4d32-9f47-8a94d5ee7a71 X-Archives-Hash: e990d334562a5ab26fff9c986e994d47 --nextPart5689896.P9onPJ0SQR Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 07 June 2006 11:13, Brian Harring wrote: > Resurrecting this issue (yet another round) since FEATURES=3Ddebug-build > was shoved in... yes, i forced the issue after requesting feedback several times and getting= no=20 further blocking input > 1) flip on nostrip in the restrict. > > For #1, use conditional support was added to portage somewhere around > 2.0.51_pre18; support is still there, so you can use > RESTRICT=3D"debug-build? ( nostrip )" now. =46EATURES=3Ddebug-build already takes care of the nostrip/splitdebug logic= ...=20 you'd rather have us add that one conditional line to every ebuild ? > 2) adjust CX*FLAGS, LDFLAGS > > As for #2, we already have eclasses mangling flags, this is no > different. sure it is ... again, you'd have us utilize the eclass in every single pack= age=20 instead of having a sane default via portage for everything ? > Two approaches to this- > 1) FEATURES=3D"debug-build". > pros: > 1) doesn't require modifying anything in the tree. everyone gets it for free > cons: > 1) no way to know if the feature will actually affect a pkg (won't > do jack to a pure python/perl/shell/ruby pkg, no point in even > trying) true, but do you really expect debug output from shell scripts > 2) FEATURES are not controllable via any package.* file. only because the portage guys have refused to implement what many people ha= ve=20 requested over and over, telling them to use bashrc hacks instead > 3) pkgs that support debug builds, but are not affected by trying to > set a default set of *FLAGS have to now go and check FEATURES to > discern if they should produce a debug build. like what ? whether you're checking USE or FEATURES, it's the same thing > 4) no way to make the debug-build option associative to deps; simple > example, consider mysql python bindings. Debug info there quite > likely isn't all that useful for a segfault- if the horkage occurs > in mysql, you just get the usual ?? backtrace, and wind up having > to take a second manual step of rebuilding mysql with debug > enabled. how is this specific to using FEATURES ? you have to manually rebuild the= =20 deps whether you use USE or FEATURES > 5) cannot control the setting per package. way to duplicate (2) so that the cons list would be bigger than your pro li= st=20 below > 2) USE=3D"debug-build" > pros: > 1) it's explicit. if the package can generate a debug-build version > of itself, you see the debug-build flag in it's IUSE. true > 2) appropriate designed eclass, ebuild can specify up front any > nonstandard *flags additions that should be made- for example, > ciaran's suggestion to mangle CXXFLAGS when dealing with STL so > that the result is useful. the flags ciaran suggested would be useful for all of C++, regardless of STL > Possible via FEATURES, but ebuild would=20 > have to test features for it (something it should be mostly unaware > of, features are mainly pkg manager directives, not ebuild). i dont get it ... are you arguing for FEATURES=3Ddebug-build or USE=3Ddebug= =2Dbuild=20 here ? > 3) via use deps, it's possible to address 1.4 from above- > python-mysql can just slip in a > "debug-build? ( dev-db/mysql[debug-build] )", one less manual step > required. sounds like you're duplicating the work of RDEPEND split that people have=20 already decided on doing > 4) use flags can be controlled per package via package.use; you can > force $YOUR_PERSONAL_PROJECT to always be built with debug symbols > cleanly. which is a moot point once portage peeps actually implement a package.env > cons: > 1) requires modifying the tree, and introduction of eclass for it. this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do= =20 not want to go through every single package i maintain and add 'debug-build= '=20 to IUSE or 'inherit some-new-eclass' if the large majority of packages are going to be taking advantage of a=20 feature, isnt the logical thing to opt everyone in rather than forcing the= =20 majority to opt themselves in ? > 2) existing USE=3D"debug" (namely nano) is used to enable runtime > changes, asserts, etc; would have two sets of flags, debug-build > and runtime changes (debug flag). how is this a con ? you provide no way of letting this useful runtime debu= g=20 code from being enabled =2Dmike --nextPart5689896.P9onPJ0SQR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iQIVAwUARIb9qkFjO5/oN/WBAQJqLQ/+NH3Zbwa5o+jV3D6C7axkrnvftJYE2U9d DuuSY/392qwzjGcscvjpHG7TXEF0pikEvCiqrUgK8/PMUnr3WskIuBzrvrUppR2U gJpDa1Be7XR/whjnMIMtMEo3eAqasg4PTpbOMk35qDiZzhRQIRd+I2Pazg1w/9BC wX1lkmwwwCmcHujr+LkGIZPAlNtc2L0ITONWVmG74CLaj4lYokyg2Y/1/kqz0uJS Fz5Jpxt1aDfbwhTb9Kkadz3fR7+gHxsA2WLkgHSEKhl1QFlmhzmuT5TLQOfp8CVX BZWrSoDw/c8ObVSLI65/1gfkg4JyNtfV3IN4teo8U67EPUDKIgL0CLTiS86PfhJJ KvKsZqp90pMeXr0x5Djv1e+Rg7cHmK1LVfXIq8wAVlXbzpwPGv1WTeeiQrLle1Nu 9nFrFnS8vo7nPQ3MM8cTCm+xLvXPG4hlQwAykN7NEUoFBRFBNKIU2JQe8MTAQlBa mwCmDef91jHA+oW4nVu9mxwkaI9AhqCD5MwyWtBHLDQ6BhPpoOwqxOHejGiLLRTT BJLmeNgNLvvf5qEa1qZMPttP/chd3NjuXc+jskbJyUT+bUxSS++XeX80K93RDvt2 VK8a3xZ3ZC01JGmRXp7un0xZDJkIz4uudj+hw2atmOaXHmutUPG5Sz7n/n5f1t8w g85NMsQRLH4= =S0GN -----END PGP SIGNATURE----- --nextPart5689896.P9onPJ0SQR-- -- gentoo-dev@gentoo.org mailing list