Re: [gentoo-dev] Replacing cpu-feature USE flags

["Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

On Friday 07 July 2006 01:16, Ciaran McCreesh wrote:
> Please try to keep this technical, even if your co-developers can't...
You started this.

> * it's relying upon non-guaranteed GCC internals.
Not that internals, that part is guaranteed to work, or we cannot consider 
guaranteed __PIC__ either, and we rely on that heavily.

> * it's relying upon GCC knowing the state of the underlying system,
> which fails at least for VIS.
Define "state of underlying system" because that is not a complete definition. 
This is not a state machine we're talking about, and we're not in science 
class.

> * it's removing the ability to get access to the data at the metadata
> phase, leading to what you yourself called a "regression".
Yes, a little regression. That's what pro&cons consideration are needed for 
after all.

> * it's forcing users to use insane CFLAGS hacks, which we've spent years
> telling them not to do and for good reason, to get back to previous
> behaviour.
No, we never spent years telling them not to use your so-called "CFLAGS hacks" 
that are rather a proper usage of what the compiler gives you.

I would _not_ ask someone why he's using -mno-mmx for instance, but I _will_ 
tell someone using

-march=athlon64 -mmmx -msse -msse2 -m3dnow -m3dnowex

that he's not doing anything useful.
Kinda like I do to people who uses -Wl,--enable-new-dtags [1]

> * a large part of the justification is based upon a misunderstanding of
> how cross compilation should be done. The correct way around this
> problem was already posted to the thread by solar.
No I'm not misunderstand how cross compilation should be done with a package 
manager. I'm saying that this will anyway give a hand to that. What I was 
referring to mostly comes down to the fact that, if I want to build a bin 
package for amd64 nocona arch, right now I am not guaranteed that setting 
CFLAGS to -march=nocona will produce the right result.

> * it's removing transparency and simplicity and replacing them with
> obfuscation and complexity.
It's removing green and yellow and adding black and white.
Your words are useless unless you explain them.

> * it's taking a variable with a well defined purpose and abusing it for
> something unrelated.
No it is not. Want to get the news? People at binutils were discussing about 
adding -march support to gas, so that it would refuse to build asm sources 
that contains instructions not supported by the -march value passed.
So using -march=i586 with mmx useflag wouldn't work anymore.

It does make sense to them and it does to me too.

> Will that lot do or would you like some more?
You have the innate ability to find more arguments when the ones you brought 
on are not accepted.

For what concerns me, I brought the idea, I find the single regression 
acceptable, I find it a proper usage of $CFLAGS variable, I find the 
internals guaranteed enough to work. My work is done here, I leave to anybody 
else to say what they think, as it seems I'm not the only one thinking this 
is a good idea.

[1] 
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/22/nonsensical-hacks-why-i-find-kdenewldflags-stupid
-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]