Dnia 2015-01-26, o godz. 16:40:35 Alexis Ballier <[email protected]> napisał(a):
> On Mon, 26 Jan 2015 16:20:10 +0100 > Michał Górny <[email protected]> wrote: > > > Dnia 2015-01-26, o godz. 12:41:00 > > Alexis Ballier <[email protected]> napisał(a): > > > > > On Sat, 24 Jan 2015 00:35:39 +0100 > > > Michał Górny <[email protected]> wrote: > > > > > > > Title: CPU_FLAGS_X86 introduction > > > > Author: Michał Górny <[email protected]> > > > > 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. -- Best regards, Michał Górny
pgp_6Bu3iDUeY.pgp
Description: OpenPGP digital signature
