From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: New global use flags: 3dnowext, mmxext, ssse3, sse4_1, avx, avx2
Date: Mon, 16 Dec 2013 22:48:23 +0200 [thread overview]
Message-ID: <52AF6717.2080909@gmail.com> (raw)
In-Reply-To: <52AF5FD8.70505@gentoo.org>
On 16/12/2013 22:17, Michael Orlitzky wrote:
> On 12/16/2013 01:21 PM, Alan McKinnon wrote:
>>>
>>> "Enable use of the SSSE3 instruction set (NOT sse3). This is needed by
>>> projects which contain assembly code or which use certain compiler
>>> intrinsics. It is not a replacement for CFLAGS and friends."
>>
>> The second and third sentences add nothing to the description. They only
>> describe how cpu instruction sets in general work and are used, but tell
>> you nothing about ssse3.
>
> USE flags are a user interface, not documentation. A good description is
> one that helps the user decide, "do I want to enable this?" I'm not
> particular about the wording -- and my use of "needed" was a mistake --
> but with that purpose in mind, a good description should contain,
>
> 1. Why might I want to enable this?
>
> 2. Why might I want to disable this?
>
> So e.g. my description is missing #2, "You should not enable this unless
> you have a processor supporting SSSE3."
>
>
>> then modifying all cpu instruction set flags similarly
>
> Yup.
Is it worthwhile adding a link in the description to a resource that
describes a USE flag in greater detail?
Most flags are obvious as to what they do, like jpeg/png/gif: the user
simply asks himself if he wants to use those formats. Most flags are
like this, and come down to user preference; portage merges in any
missing parts required
cpu sets are different: they also depend on whether they CAN be used in
a given environment. Portage cannot know if ssse3 will work for the cpu
running the code so cannot fill in the missing bits. The user must first
check if the intended cpu supports ssse3 at all (often preceded by
finding out how to find this out).
That's a lot of vital ,necessary info and it deserves the full
documentation treatment. A USE description is not the place for that,
but a link could work nicely. Especially if the linked page describes
the intent and usage of the USE flag in full.
--
Alan McKinnon
alan.mckinnon@gmail.com
next prev parent reply other threads:[~2013-12-16 20:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-15 23:34 [gentoo-dev] New global use flags: 3dnowext, mmxext, ssse3, sse4_1, avx, avx2 Matt Turner
2013-12-16 0:20 ` Andreas K. Huettel
2013-12-16 0:30 ` Matt Turner
2013-12-16 1:13 ` Francesco R.
2013-12-16 12:07 ` Jeroen Roovers
2013-12-16 23:07 ` Rick "Zero_Chaos" Farina
2013-12-18 17:48 ` Jeroen Roovers
2013-12-16 10:44 ` [gentoo-dev] " Duncan
2013-12-16 15:38 ` Michael Orlitzky
2013-12-16 18:21 ` Alan McKinnon
2013-12-16 20:17 ` Michael Orlitzky
2013-12-16 20:48 ` Alan McKinnon [this message]
2013-12-18 18:49 ` Matt Turner
2013-12-19 12:11 ` [gentoo-dev] " Jan Matejka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52AF6717.2080909@gmail.com \
--to=alan.mckinnon@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox