[gentoo-dev] Re: Fixing eclass code relying on ${IUSE} greps?
Il giorno mer, 14/09/2011 alle 12.38 +0200, Michał Górny ha scritto: Honestly, I'm ready to remove all relevant code in autotools-utils.eclass and fix all ebuilds in gx86 Sunrise using it. But if that's not the path we're going to take, I'd like to avoid changing API then. If that means that you won't just add --enable-debug/--disable-debug on ebuilds just because they declare IUSE=debug then please do so. It's one of the worst ideas I have ever seen implemented :| -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Fixing eclass code relying on ${IUSE} greps?
On 09/14/2011 02:06 PM, Diego Elio Pettenò wrote: Il giorno mer, 14/09/2011 alle 12.38 +0200, Michał Górny ha scritto: Honestly, I'm ready to remove all relevant code in autotools-utils.eclass and fix all ebuilds in gx86 Sunrise using it. But if that's not the path we're going to take, I'd like to avoid changing API then. If that means that you won't just add --enable-debug/--disable-debug on ebuilds just because they declare IUSE=debug then please do so. It's one of the worst ideas I have ever seen implemented :| I second that. I've been yelling about it for years... Same for the stupid assumption gnome2.eclass does with IUSE=doc for gtk-doc
Re: [gentoo-dev] Re: Fixing eclass code relying on ${IUSE} greps?
On Wed, Sep 14, 2011 at 4:50 PM, Samuli Suominen ssuomi...@gentoo.org wrote: I second that. I've been yelling about it for years... Same for the stupid assumption gnome2.eclass does with IUSE=doc for gtk-doc For reference, ye olde bug: https://bugs.gentoo.org/show_bug.cgi?id=262491 -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: Fixing eclass code relying on ${IUSE} greps?
On Wed, 14 Sep 2011 13:06:23 +0200 Diego Elio Pettenò flamee...@gentoo.org wrote: Il giorno mer, 14/09/2011 alle 12.38 +0200, Michał Górny ha scritto: Honestly, I'm ready to remove all relevant code in autotools-utils.eclass and fix all ebuilds in gx86 Sunrise using it. But if that's not the path we're going to take, I'd like to avoid changing API then. If that means that you won't just add --enable-debug/--disable-debug on ebuilds just because they declare IUSE=debug then please do so. It's one of the worst ideas I have ever seen implemented :| Well, the other thing is IUSE=static-libs. I don't like it either but this is probably a bigger case than the other. The main resolution as I see it, is to simply drop IUSE=static-libs from a lot of ebuilds where static libs aren't actually required by anything or anyone. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Fixing eclass code relying on ${IUSE} greps?
Il giorno mer, 14/09/2011 alle 22.03 +0200, Michał Górny ha scritto: The main resolution as I see it, is to simply drop IUSE=static-libs from a lot of ebuilds where static libs aren't actually required by anything or anyone. I would point at an old post of mine: http://blog.flameeyes.eu/2009/09/28/removing-la-files-for-dum-w-uncertain-people just to give an idea of where you can safely drop static-libs altogether. Or to the most recent one on the topic: http://blog.flameeyes.eu/2011/08/29/useless-flag-static-libs that ignores one obvious case (the one where you have NO headers in either the package or linked packages — the latter is the case for most X11 libs nowadays). And make sure you check against the version of the package you're adding static-libs to, before saying that it does install headers (or the other way around). -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Fixing eclass code relying on ${IUSE} greps?
On Wed, Sep 14, 2011 at 16:03, Michał Górny wrote: Well, the other thing is IUSE=static-libs. I don't like it either but this is probably a bigger case than the other. The main resolution as I see it, is to simply drop IUSE=static-libs from a lot of ebuilds where static libs aren't actually required by anything or anyone. no ... the current policy (and i see no reason to change it) is: - always build shared and static libs - always build shared libs and control static libs via USE=static-libs so if the library can be statically linked against, the ebuild needs to support it. a valid test is not does any other package in the tree want to link against this, nor is i dont want static libs, and i cant find anyone who does. most people dont want to do static linking most of the time, but that number is not 0. -mike
