| 1 |
On Friday 07 July 2006 01:16, Ciaran McCreesh wrote: |
| 2 |
> Please try to keep this technical, even if your co-developers can't... |
| 3 |
You started this. |
| 4 |
|
| 5 |
> * it's relying upon non-guaranteed GCC internals. |
| 6 |
Not that internals, that part is guaranteed to work, or we cannot consider |
| 7 |
guaranteed __PIC__ either, and we rely on that heavily. |
| 8 |
|
| 9 |
> * it's relying upon GCC knowing the state of the underlying system, |
| 10 |
> which fails at least for VIS. |
| 11 |
Define "state of underlying system" because that is not a complete definition. |
| 12 |
This is not a state machine we're talking about, and we're not in science |
| 13 |
class. |
| 14 |
|
| 15 |
> * it's removing the ability to get access to the data at the metadata |
| 16 |
> phase, leading to what you yourself called a "regression". |
| 17 |
Yes, a little regression. That's what pro&cons consideration are needed for |
| 18 |
after all. |
| 19 |
|
| 20 |
> * it's forcing users to use insane CFLAGS hacks, which we've spent years |
| 21 |
> telling them not to do and for good reason, to get back to previous |
| 22 |
> behaviour. |
| 23 |
No, we never spent years telling them not to use your so-called "CFLAGS hacks" |
| 24 |
that are rather a proper usage of what the compiler gives you. |
| 25 |
|
| 26 |
I would _not_ ask someone why he's using -mno-mmx for instance, but I _will_ |
| 27 |
tell someone using |
| 28 |
|
| 29 |
-march=athlon64 -mmmx -msse -msse2 -m3dnow -m3dnowex |
| 30 |
|
| 31 |
that he's not doing anything useful. |
| 32 |
Kinda like I do to people who uses -Wl,--enable-new-dtags [1] |
| 33 |
|
| 34 |
> * a large part of the justification is based upon a misunderstanding of |
| 35 |
> how cross compilation should be done. The correct way around this |
| 36 |
> problem was already posted to the thread by solar. |
| 37 |
No I'm not misunderstand how cross compilation should be done with a package |
| 38 |
manager. I'm saying that this will anyway give a hand to that. What I was |
| 39 |
referring to mostly comes down to the fact that, if I want to build a bin |
| 40 |
package for amd64 nocona arch, right now I am not guaranteed that setting |
| 41 |
CFLAGS to -march=nocona will produce the right result. |
| 42 |
|
| 43 |
> * it's removing transparency and simplicity and replacing them with |
| 44 |
> obfuscation and complexity. |
| 45 |
It's removing green and yellow and adding black and white. |
| 46 |
Your words are useless unless you explain them. |
| 47 |
|
| 48 |
> * it's taking a variable with a well defined purpose and abusing it for |
| 49 |
> something unrelated. |
| 50 |
No it is not. Want to get the news? People at binutils were discussing about |
| 51 |
adding -march support to gas, so that it would refuse to build asm sources |
| 52 |
that contains instructions not supported by the -march value passed. |
| 53 |
So using -march=i586 with mmx useflag wouldn't work anymore. |
| 54 |
|
| 55 |
It does make sense to them and it does to me too. |
| 56 |
|
| 57 |
> Will that lot do or would you like some more? |
| 58 |
You have the innate ability to find more arguments when the ones you brought |
| 59 |
on are not accepted. |
| 60 |
|
| 61 |
For what concerns me, I brought the idea, I find the single regression |
| 62 |
acceptable, I find it a proper usage of $CFLAGS variable, I find the |
| 63 |
internals guaranteed enough to work. My work is done here, I leave to anybody |
| 64 |
else to say what they think, as it seems I'm not the only one thinking this |
| 65 |
is a good idea. |
| 66 |
|
| 67 |
[1] |
| 68 |
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/22/nonsensical-hacks-why-i-find-kdenewldflags-stupid |
| 69 |
-- |
| 70 |
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ |
| 71 |
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE |
Archives