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

[Ciaran McCreesh]

On Fri, 7 Jul 2006 01:39:05 +0200 Diego 'Flameeyes' Pettenò
<flameeyes@g.o> wrote:
| > * 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.

With __PIC__ there's not much choice. Here there is.

| > * 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.

In the VIS case, there are plenty of situations where GCC will think
that the underlying system doesn't do VIS (because that's the only way
of stopping it from producing broken code), but where hand-crafted VIS
code is fine and desirable.
 
| > * 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.

Wrong. We did.

| > * 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.

Well no, if you're cross compiling you should be using an entirely
separate configuration setup.

| > * 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.

Basic software engineering principles. Or basic English, if you prefer.

Transparency: what is happening is obvious. That is to say, the CFLAGS
variable affects flags that are passed when compiling C, and the
USE_THESE_FANCY_X86_EXTRAS variable affects the fancy x86 extras that
are used in cases where there are optional fancy x86 extras.

Simplicity: what is happening is happening without unnecessary extras
or complication.

Obfuscation: what is happening is not obvious, and is being hidden. For
example, the CFLAGS variable doesn't actually just alter CFLAGS, it
also triggers some unrelated code that turns on other unrelated
features. It's like having a function called display_person(person)
that as a side effect also deducts five percent of that person's salary.

Complexity: what is happening takes many steps and relies upon many
different systems, assumptions or code paths. Like, say, a scary hack
of a function where previously there was just a variable.

| > * 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.

CFLAGS != ASFLAGS.

| > 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.

Well yes. There're all sorts of things wrong with this proposal, and
some of them are more obvious than others. Still, it makes sense to
start with the easy ones and see whether they'll suffice before moving
onto more complex objections...

| I find it a proper usage of $CFLAGS variable

Ouch.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@g.o mailing list