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