Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/9/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: Basically, if you're using daft CFLAGS you're on your own. Some ebuilds might filter them, some ebuilds might die and some ebuilds might let them through. Developers are under no obligation to add code to save users from their own stupidity, but they might do so if you ask nicely. Please re-read all the words in the previous messages. What I would like to discuss is not about helping users, but about making our job easier. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On Sat, 15 Jul 2006 13:54:52 +0200 Denis Dupeyron [EMAIL PROTECTED] wrote: | On 7/9/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: | Basically, if you're using daft CFLAGS you're on your own. Some | ebuilds might filter them, some ebuilds might die and some ebuilds | might let them through. Developers are under no obligation to add | code to save users from their own stupidity, but they might do so | if you ask nicely. | | Please re-read all the words in the previous messages. What I would | like to discuss is not about helping users, but about making our job | easier. If you want your job to be easier, just INVALID any bug that comes in with daft CFLAGS... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/9/06, Denis Dupeyron [EMAIL PROTECTED] wrote: 2) If yes, are there any other flags that ebuilds should die on ? My (user) opinion is that ebuilds should not die on CFLAGS, at least not until per-package CFLAGS are implemented. Now if someone is crazy enough to enable -ffast-math globally or specifically for python in that situation, well, die, spin the cpu fan backwards, melt the hard disk down and sell it for scrap, whatever you want! -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On Mon, 2006-07-10 at 01:34 -0700, Richard Fish wrote: On 7/9/06, Denis Dupeyron [EMAIL PROTECTED] wrote: 2) If yes, are there any other flags that ebuilds should die on ? My (user) opinion is that ebuilds should not die on CFLAGS, at least not until per-package CFLAGS are implemented. per pkg cflags are here already it would fall under the per pkg env variables. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
Denis Dupeyron wrote: This, for me, triggers 3 questions that are gentoo-dev@ material : 1) Should all ebuilds that currently filter --fast-math die on its presence instead of filtering it ? I don't think we should die on anything, if a user wants a particular CFLAG, generally the default should be to let them use it. A warning with a pause may also suffice. Currently the amd64 profiles do some testing for broken USE flags. If the user has flags that gcc will not accept (ie errors out with invalid command line option), our profile.bashrc will filter them out completely. If they have a flag that is on a list of pre-defined bad flags it will warn the user about the flag and sleep for 5 seconds. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
[ resending this, the original appears to have been eaten. ] On Sun, 9 Jul 2006 23:24:24 +0200 Denis Dupeyron [EMAIL PROTECTED] wrote: | 1) Should all ebuilds that currently filter --fast-math die on its | presence instead of filtering it ? http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html Basically, if you're using daft CFLAGS you're on your own. Some ebuilds might filter them, some ebuilds might die and some ebuilds might let them through. Developers are under no obligation to add code to save users from their own stupidity, but they might do so if you ask nicely. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On Sun, 9 Jul 2006 23:24:24 +0200 Denis Dupeyron [EMAIL PROTECTED] wrote: | 1) Should all ebuilds that currently filter --fast-math die on its | presence instead of filtering it ? http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html Basically, if you're using daft CFLAGS you're on your own. Some ebuilds might filter them, some ebuilds might die and some ebuilds might let them through. Developers are under no obligation to add code to save users from their own stupidity, but they might do so if you ask nicely. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote: per pkg cflags are here already it would fall under the per pkg env variables. Please forgive my stupidity, but the only place I could see to set a env var per package was /etc/portage/bashrc. Is that what you are referring to? -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Fish wrote: On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote: per pkg cflags are here already it would fall under the per pkg env variables. Please forgive my stupidity, but the only place I could see to set a env var per package was /etc/portage/bashrc. Is that what you are referring to? You're close. There is now a per-package bashrc implementation included in $PORTDIR/profiles/base/profile.bashrc. It's kind of silly imo, when the user can simply put that same code in /etc/portage/bashrc, but this is how it is. :) Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEsolv/ejvha5XGaMRAkeoAJ95/lUC/pSZHeo09JOp/PCOx0HkxwCgoBVl zJW3/SnRt48YXixrIFxt+zo= =mg/P -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/10/06, Zac Medico [EMAIL PROTECTED] wrote: Richard Fish wrote: On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote: per pkg cflags are here already it would fall under the per pkg env variables. Please forgive my stupidity, but the only place I could see to set a env var per package was /etc/portage/bashrc. Is that what you are referring to? You're close. There is now a per-package bashrc implementation included in $PORTDIR/profiles/base/profile.bashrc. It's kind of silly imo, when the user can simply put that same code in /etc/portage/bashrc, but this is how it is. :) Ah, thanks, I see it now. I have to say I dislike allowing this backdoor method to set CFLAGS, as they won't show up in emerge --info or emerge -pv pkg. You'd have to see the actual build output to see the nasty flags, which you might not even think to ask for if a package builds fine but crashes randomly later. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
Richard Fish wrote: I have to say I dislike allowing this backdoor method to set CFLAGS, as they won't show up in emerge --info or emerge -pv pkg. You'd have to see the actual build output to see the nasty flags, which you might not even think to ask for if a package builds fine but crashes randomly later. Sounds like your after bug 95741: http://bugs.gentoo.org/show_bug.cgi?id=95741 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/10/06, Simon Stelling [EMAIL PROTECTED] wrote: Sounds like your after bug 95741: http://bugs.gentoo.org/show_bug.cgi?id=95741 Yeah, that would be nice! :-) -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
Richard Fish wrote: I have to say I dislike allowing this backdoor method to set CFLAGS, as they won't show up in emerge --info or emerge -pv pkg. You'd have to see the actual build output to see the nasty flags, which you might not even think to ask for if a package builds fine but crashes randomly later. How about `cat /var/db/pkg/$category/$package-$version/CFLAGS`? You can't rely on emerge --info anyway, because it shows _current_ flags rather than flags the package was built with. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Dying on some CFLAGS instead of filtering them.
Dear devs, In bug #139412, I ask Paul de Vriese why he thinks python should die on --fast-math instead of just filtering it. Here's his answer : Denis, quite simple. -ffast-math is broken and short-sighted for a global flag. Filtering gives the shortsighted message that it works globally, while it is not suited for any package not specifically tested for it. As it breaks python, dieing makes people understand that it does not work on python. It is better than the alternative of not looking for it at all. This, for me, triggers 3 questions that are gentoo-dev@ material : 1) Should all ebuilds that currently filter --fast-math die on its presence instead of filtering it ? 2) If yes, are there any other flags that ebuilds should die on ? 3) Suppose that -ftracer, for example, is one of those, and knowing that enabling -fprofile-use enables -ftracer, shouldn't ebuilds also die on use of -fprofile-use ? It's only an example, this situation will exist for other pairs of flags. The hidden question behind these three is : shouldn't we have a something that enables us to safely handle this kind of situations ? Like some kind of system- and/or architecture-wide flag mask that could be overriden by the ebuild and/or the user (at his own risk) ? This could potentialy reduce the number of bugs that poor old bugzie has to cope with, and simplify ebuild writing and maintenance. If we already have such a thing, I'm sure you guys know where the cluebat is... But in any case, questions 1), 2) and 3) still need to be answered. Denis. -- gentoo-dev@gentoo.org mailing list
