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 |