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

[Ciaran McCreesh]

On Thu, 6 Jul 2006 20:07:00 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@g.o> wrote:
| On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
| > And for a single compile?
|
| I always leave the two of them in sync, even C++ apps might have
| parts building CFLAGS. In case you know you're going to use only C++
| is not difficult to use
| 
| CFLAGS=${CXXFLAGS} has_cpuset 3dnow
| 
| don't you think?

Ah yes, yet more added complexity that's going to be forgotten and that
will lead to weird breakages.

Incidentally, syncing CFLAGS and CXXFLAGS really isn't a good idea if
you want your C compiler to work and produce vaguely sane code.

| > And your assumption would be wrong. I can assure you that relying
| > upon -march doing anything sensible with __MAGIC__ is entirely
| > unsafe. Go and look at the VIS handling if you want a perfect
| > example.
|
| Okay, maybe VIS handling is broken. But we can rely pretty safely on
| x86, amd64 and PPC gcc to know the table of arches and extensions
| supported. Remember that I asked to talk with SPARC team for VIS just
| because I only know about the other three arches.

Not really. The __MAGIC__ is subject to change whenever any GCC person
feels like it. It also doesn't work in cases where people have one of
those nasty corner case CPUs (such as the 4m, which is not an m and not
really a 4 either, or the USIV, or the r8k) that's best off with a weird
march.

| > No no. Where "regain control" means the user has to screw around
| > with nasty hacks and pray, rather than setting a well defined,
| > specific variable.
|
| Find me a reason to do that, a part for broken MMX code that should
| be disabled on the ebuild itself already.

Well that's kinda the point. Since ebuild developers don't have access
to every kind of CPU, relying upon the ebuilds getting it right isn't a
very good idea.

| > Uh. USE flags are available at DEPEND time.
|
| If you talk about the nasm dependency, then it is rare, most of the
| MMX support is inline in C sources anyway.

'most'?
 
| > And at the metadata phase?
|
| Should be already transparent or something is strange. nasm is
| simpler to add the dependency for x86, there is really few people not
| enabling mmx already. Yes it is a bit of regression, but for a small
| percentage of users, while there's more safety for many other people.

Since when was Gentoo about covering up for idiots who can't get their
ricing correct at the expense of those who know what they're doing?
 
| > Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the
| > contrary.
|
| This ain't no magic. The magic is in the _CODE_ that GCC creates, but
| not in the _DEFINES_ that GCC emits.

Sure it's magic. The __DEFINES__ aren't reliable. The GCC people change
them around now and again for compatibility with other compilers.
 
| > You're trying to guess what the user wants based upon hairy magic,
| No, about their chosen architecture.
| 
| > rather than doing what the user says (aren't you always yelling at
| > upstreams for doing that?)
|
| The user asks for athlon64 support? They get athlon64 (mmx, 3dnow,
| 3dnowex, sse, sse2)
| The user asks for G3 support? They get G3 (nothing)
| The user asks for Pentium4 support? They get what they want (mmx,
| sse, sse2, sse3 in case)
 
Setting CFLAGS and praying is not asking for something. Setting a
MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.

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


-- 
gentoo-dev@g.o mailing list