1 |
Dnia 2015-01-27, o godz. 10:18:37 |
2 |
Alexis Ballier <aballier@g.o> napisał(a): |
3 |
|
4 |
> On Mon, 26 Jan 2015 20:09:18 +0100 |
5 |
> Michał Górny <mgorny@g.o> wrote: |
6 |
> |
7 |
> > Dnia 2015-01-26, o godz. 16:40:35 |
8 |
> > Alexis Ballier <aballier@g.o> napisał(a): |
9 |
> > |
10 |
> > > On Mon, 26 Jan 2015 16:20:10 +0100 |
11 |
> > > Michał Górny <mgorny@g.o> wrote: |
12 |
> > > |
13 |
> > > > Dnia 2015-01-26, o godz. 12:41:00 |
14 |
> > > > Alexis Ballier <aballier@g.o> napisał(a): |
15 |
> > > > |
16 |
> > > > > On Sat, 24 Jan 2015 00:35:39 +0100 |
17 |
> > > > > Michał Górny <mgorny@g.o> wrote: |
18 |
> > > > > |
19 |
> > > > > > Title: CPU_FLAGS_X86 introduction |
20 |
> > > > > > Author: Michał Górny <mgorny@g.o> |
21 |
> > > > > > Content-Type: text/plain |
22 |
> > > > > > Posted: 2015-01-xx |
23 |
> > > > > > Revision: 1 |
24 |
> > > > > > News-Item-Format: 1.0 |
25 |
> > > > > > Display-If-Keyword: amd64 ~amd64 x86 ~x86 |
26 |
> > > > > |
27 |
> > > > > but.... why ? |
28 |
> > > > > will you write another news item for other arches ? |
29 |
> > > > |
30 |
> > > > Are there other arches using CPU_FLAGS_X86? ;) But seriously, the |
31 |
> > > > item is quite arch-specific. Other arches are likely to have |
32 |
> > > > kinda specific flags with rules for choosing them, another script |
33 |
> > > > etc. |
34 |
> > > |
35 |
> > > I think it is better to have it done all in one pass: even if there |
36 |
> > > is no script, it is just as good as it is today. |
37 |
> > > |
38 |
> > > My concern is: This will clutter e.g. ffmpeg ebuild by having two |
39 |
> > > ways to pass cpu flags, depending on the arch, and will give a kind |
40 |
> > > of silly output with "altivec" or "neon" as standard useflags but |
41 |
> > > x86 cpu flags as USE_EXPAND. This is too much inconsistent to me. |
42 |
> > |
43 |
> > I understand your concern but unless someone's going to do the work |
44 |
> > for other arches, I doubt there's a point in waiting forever. Script |
45 |
> > is a minor issue, but someone has to figure out how various packages |
46 |
> > behave and what flags to use. |
47 |
> > |
48 |
> |
49 |
> It doesn't have to be perfect, just consistent. As of figuring out how |
50 |
> to have such flags, I already gave you the link: profiles/base/use.mask. |
51 |
|
52 |
I'm afraid this mail pretty much proves why we shouldn't do this. |
53 |
|
54 |
> Let's see: |
55 |
> |
56 |
> # ppc arch specific USE flags |
57 |
> altivec |
58 |
> pbbuttonsd |
59 |
|
60 |
Is this even a USE flag? Maybe you meant USE=macbook or something like |
61 |
this? |
62 |
|
63 |
> ppcsha1 |
64 |
|
65 |
This is not a CPU feature, and i'm not sure if this should be |
66 |
an explicit flag at all. This sounds like 'use ppc' + 'use asm'. |
67 |
|
68 |
> # mips arch specific USE flags |
69 |
> n32 |
70 |
> n64 |
71 |
|
72 |
Those are rather covered in ABI_MIPS. |
73 |
|
74 |
> fixed-point |
75 |
> loongson2f |
76 |
> mips32r2 |
77 |
> mipsdspr1 |
78 |
> mipsdspr2 |
79 |
> mipsfpu |
80 |
|
81 |
The MIPS team will likely want to drop some of the prefixes. |
82 |
|
83 |
> # sparc arch specific USE flags |
84 |
> vis |
85 |
> ultra1 |
86 |
> |
87 |
> etc. |
88 |
> |
89 |
> grep their desc in use.desc or .local.desc and paste these to |
90 |
> profiles/desc/cpu_flags_xxx.desc, and you're done. |
91 |
> if you want to do things better, open a bug for relevant arch team to |
92 |
> review it, improve it or remove useless stuff; it'd be better tracked |
93 |
> than a discussion here. |
94 |
|
95 |
True, a bug is a good idea. |
96 |
|
97 |
> Anyway, flags renamings will have to be done on a per-package basis, |
98 |
> probably with a bug openened and certainly with proper review done, so |
99 |
> that being x86* only or all arches makes little to no difference. Even |
100 |
> better: you won't have me on your back ranting against pointless |
101 |
> inconsistencies :) |
102 |
|
103 |
The point is not to publish a news item telling people to update flags |
104 |
before we decide on the final flags. The list pretty much covered x86 |
105 |
flag review, and found issues that we were able to fix before |
106 |
committing. |
107 |
|
108 |
-- |
109 |
Best regards, |
110 |
Michał Górny |