Dnia 2015-01-27, o godz. 10:18:37
Alexis Ballier <aballier@gentoo.org> napisał(a):
> On Mon, 26 Jan 2015 20:09:18 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > Dnia 2015-01-26, o godz. 16:40:35
> > Alexis Ballier <aballier@gentoo.org> napisał(a):
> >
> > > On Mon, 26 Jan 2015 16:20:10 +0100
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > >
> > > > Dnia 2015-01-26, o godz. 12:41:00
> > > > Alexis Ballier <aballier@gentoo.org> napisał(a):
> > > >
> > > > > On Sat, 24 Jan 2015 00:35:39 +0100
> > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > >
> > > > > > Title: CPU_FLAGS_X86 introduction
> > > > > > Author: Michał Górny <mgorny@gentoo.org>
> > > > > > Content-Type: text/plain
> > > > > > Posted: 2015-01-xx
> > > > > > Revision: 1
> > > > > > News-Item-Format: 1.0
> > > > > > Display-If-Keyword: amd64 ~amd64 x86 ~x86
> > > > >
> > > > > but.... why ?
> > > > > will you write another news item for other arches ?
> > > >
> > > > Are there other arches using CPU_FLAGS_X86? ;) But seriously, the
> > > > item is quite arch-specific. Other arches are likely to have
> > > > kinda specific flags with rules for choosing them, another script
> > > > etc.
> > >
> > > I think it is better to have it done all in one pass: even if there
> > > is no script, it is just as good as it is today.
> > >
> > > My concern is: This will clutter e.g. ffmpeg ebuild by having two
> > > ways to pass cpu flags, depending on the arch, and will give a kind
> > > of silly output with "altivec" or "neon" as standard useflags but
> > > x86 cpu flags as USE_EXPAND. This is too much inconsistent to me.
> >
> > I understand your concern but unless someone's going to do the work
> > for other arches, I doubt there's a point in waiting forever. Script
> > is a minor issue, but someone has to figure out how various packages
> > behave and what flags to use.
> >
>
> It doesn't have to be perfect, just consistent. As of figuring out how
> to have such flags, I already gave you the link: profiles/base/use.mask.
I'm afraid this mail pretty much proves why we shouldn't do this.
> Let's see:
>
> # ppc arch specific USE flags
> altivec
> pbbuttonsd
Is this even a USE flag? Maybe you meant USE=macbook or something like
this?
> ppcsha1
This is not a CPU feature, and i'm not sure if this should be
an explicit flag at all. This sounds like 'use ppc' + 'use asm'.
> # mips arch specific USE flags
> n32
> n64
Those are rather covered in ABI_MIPS.
> fixed-point
> loongson2f
> mips32r2
> mipsdspr1
> mipsdspr2
> mipsfpu
The MIPS team will likely want to drop some of the prefixes.
> # sparc arch specific USE flags
> vis
> ultra1
>
> etc.
>
> grep their desc in use.desc or .local.desc and paste these to
> profiles/desc/cpu_flags_xxx.desc, and you're done.
> if you want to do things better, open a bug for relevant arch team to
> review it, improve it or remove useless stuff; it'd be better tracked
> than a discussion here.
True, a bug is a good idea.
> Anyway, flags renamings will have to be done on a per-package basis,
> probably with a bug openened and certainly with proper review done, so
> that being x86* only or all arches makes little to no difference. Even
> better: you won't have me on your back ranting against pointless
> inconsistencies :)
The point is not to publish a news item telling people to update flags
before we decide on the final flags. The list pretty much covered x86
flag review, and found issues that we were able to fix before
committing.
--
Best regards,
Michał Górny
