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
pgpyJw1w2B75S.pgp
Description: PGP signature
