On Thu, 6 Jul 2006 18:43:11 +0200 "Diego 'Flameeyes' Pettenò"
<[EMAIL PROTECTED]> wrote:
| On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
| > Well, you're assuming that
| Properly listing, what an arcane science.
Perhaps I should've written a Java + XML app that automatically formats
messages according to what the reader probably wants to see.
| > a) everyone's using a C compiler,
|
| No, I assume that everyone is using a compiler. You cannot have a C++
| compiler without a C compiler. The first person I see that sets
| CXXFLAGS but not CFLAGS I'm personally going to give him the "doesn't
| have a clue" prize.
And for a single compile?
| > b) that gcc has the slightest clue what it's doing,
|
| No, I assume that gcc has a big clue about which capabilities are
| available to the -march switch. I might be assuming that users have a
| clue on what they are doing, but that's an assumption I do have to
| do, or I shouldn't be working on Gentoo but on Debian, which seems
| pretty good at optimising for i386 still.
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.
| > c) that the user has no problem using nasty hacks to regain control,
|
| Where "regain control" is "doing something that could have done
| before but made actually no sense to do before. And the bashrc thing
| is not a big nasty hack, works quite well for me.
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.
| > d) that this information is only needed at compile time,
|
| Well of course use flags are available at runtime for the packages
| built to know, this is perfectly logic of you.
Uh. USE flags are available at DEPEND time.
| You really was getting out of arguments, don't you?
No, you're just not thinking this through.
| If I have to enable a configure switch I need it only at buildtime.
| If it has to be known at runtime there's the cpuid function!
And at the metadata phase?
| > e) that various gcc internal definitions won't change...
| It's like assuming that gcc will always output the correct hello
| world for
|
| int main() {
| printf("Hello, world!\n");
| return 0;
| }
|
| If it does change those values, it's going to be a killer for way
| more than just Portage.
Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
It can and does change with different GCC releases. I know there've been
GCC changes on sparc to those kinds of defines to try to play nice with
certain other compilers...
| > You're adding a lot of complexity, and thus
| > room for very weird breakages, to something that doesn't need it.
|
| You're not exposing any of such breakages, I find it to reduce
| complexity to users that cannot try to enable SSE3 on an Athlon-TBird
| system.
You're trying to guess what the user wants based upon hairy magic,
rather than doing what the user says (aren't you always yelling at
upstreams for doing that?), and all because you aren't aware
of how to cross compile correctly.
Now, please go back to justifying this thing on any merits it may have,
rather than playing the "Go and use Debian!!!1111! card.
--
Ciaran McCreesh
Mail : ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
