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,
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.
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
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
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
[ 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 ?
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
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
--
-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
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
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
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
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
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
14 matches
Mail list logo
