Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Replacing cpu-feature USE flags
Date: Thu, 06 Jul 2006 17:57:26
Message-Id: 20060706185110.46f234ce@snowdrop.home
In Reply to: Re: [gentoo-dev] Replacing cpu-feature USE flags by "Diego 'Flameeyes' Pettenò"
1 On Thu, 6 Jul 2006 18:43:11 +0200 "Diego 'Flameeyes' Pettenò"
2 <flameeyes@g.o> wrote:
3 | On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
4 | > Well, you're assuming that
5 | Properly listing, what an arcane science.
6
7 Perhaps I should've written a Java + XML app that automatically formats
8 messages according to what the reader probably wants to see.
9
10 | > a) everyone's using a C compiler,
11 |
12 | No, I assume that everyone is using a compiler. You cannot have a C++
13 | compiler without a C compiler. The first person I see that sets
14 | CXXFLAGS but not CFLAGS I'm personally going to give him the "doesn't
15 | have a clue" prize.
16
17 And for a single compile?
18
19 | > b) that gcc has the slightest clue what it's doing,
20 |
21 | No, I assume that gcc has a big clue about which capabilities are
22 | available to the -march switch. I might be assuming that users have a
23 | clue on what they are doing, but that's an assumption I do have to
24 | do, or I shouldn't be working on Gentoo but on Debian, which seems
25 | pretty good at optimising for i386 still.
26
27 And your assumption would be wrong. I can assure you that relying upon
28 -march doing anything sensible with __MAGIC__ is entirely unsafe. Go
29 and look at the VIS handling if you want a perfect example.
30
31 | > c) that the user has no problem using nasty hacks to regain control,
32 |
33 | Where "regain control" is "doing something that could have done
34 | before but made actually no sense to do before. And the bashrc thing
35 | is not a big nasty hack, works quite well for me.
36
37 No no. Where "regain control" means the user has to screw around with
38 nasty hacks and pray, rather than setting a well defined, specific
39 variable.
40
41 | > d) that this information is only needed at compile time,
42 |
43 | Well of course use flags are available at runtime for the packages
44 | built to know, this is perfectly logic of you.
45
46 Uh. USE flags are available at DEPEND time.
47
48 | You really was getting out of arguments, don't you?
49
50 No, you're just not thinking this through.
51
52 | If I have to enable a configure switch I need it only at buildtime.
53 | If it has to be known at runtime there's the cpuid function!
54
55 And at the metadata phase?
56
57 | > e) that various gcc internal definitions won't change...
58 | It's like assuming that gcc will always output the correct hello
59 | world for
60 |
61 | int main() {
62 | printf("Hello, world!\n");
63 | return 0;
64 | }
65 |
66 | If it does change those values, it's going to be a killer for way
67 | more than just Portage.
68
69 Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
70 It can and does change with different GCC releases. I know there've been
71 GCC changes on sparc to those kinds of defines to try to play nice with
72 certain other compilers...
73
74 | > You're adding a lot of complexity, and thus
75 | > room for very weird breakages, to something that doesn't need it.
76 |
77 | You're not exposing any of such breakages, I find it to reduce
78 | complexity to users that cannot try to enable SSE3 on an Athlon-TBird
79 | system.
80
81 You're trying to guess what the user wants based upon hairy magic,
82 rather than doing what the user says (aren't you always yelling at
83 upstreams for doing that?), and all because you aren't aware
84 of how to cross compile correctly.
85
86 Now, please go back to justifying this thing on any merits it may have,
87 rather than playing the "Go and use Debian!!!1111! card.
88
89 --
90 Ciaran McCreesh
91 Mail : ciaran dot mccreesh at blueyonder.co.uk
92
93
94 --
95 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Replacing cpu-feature USE flags "Diego 'Flameeyes' Pettenò" <flameeyes@g.o>