public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kent Fredric <kentnl@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH] app-portage/eclass-manpages: Add support for @DEFAULT-ASSUMED
Date: Tue, 2 May 2017 09:25:52 +1200	[thread overview]
Message-ID: <20170502092552.4d2f96bf@katipo2.lan> (raw)
In-Reply-To: <1493654576.29015.1.camel@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

On Mon, 01 May 2017 18:02:56 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> In other words, I don't think that:
> 
>   DIST_TEST      (UNSET -> "do parallel")
> 
> is more readable than:
> 
>   DIST_TEST      (UNSET)
>   ...
>   If unset, "do parallel" is assumed.
> 
> -- 

(This time on list)

If I were to take a second approach, producing a map of specific values
for a varible and their interpretations, so that the manpage emitter
could elegantly turn them into a bullet-pointed list of some
description, would that be a worthwhile alternative?


  DIST_TEST

    Values:
      - UNSET          same as "do parallel"
      - "do ..."       enable tests
      - "parallel ..." enable tests and parallelism
      - "network  ..." don't attempt to suppress network tests
      - "verbose ..."  increase test verbosity


   GENTOO_DEPEND_ON_PERL

     Values:
       - UNSET          same as "yes"
       - "yes"          depend on perl, including a slot operator for rebuild
       - "noslotop"     depend on perl, but without including the slot operator

The main objective here for me is to encourage a more clear convention
for documenting the purpose of the variable that is consistent across
eclasses, that doesn't require full reading of the DESCRIPTION to
cherry pick understandings of various isolated parts.

( Mostly, as they're typically not well structured for skim reading )

You may note the value map for DIST_TEST as stated is more-or-less
already in place for perl-module.eclass, albeit its just a hand
formatted table.

I just figure we could do more with this tree-wide if the data was
declared up-front, ( like line-wrapping the description side, using
styles for the "key" parts, etc, )

But I won't waste time throwing together such an idea if its not likely
to be deemed useful.

( I don't even want to think about what the syntax would be to document
it atm, ewww )

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-05-01 21:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-30 21:38 [gentoo-dev] [PATCH] app-portage/eclass-manpages: Add support for @DEFAULT-ASSUMED kentnl
2017-05-01 16:02 ` Michał Górny
2017-05-01 21:25   ` Kent Fredric [this message]
2017-05-01 21:54     ` Kent Fredric

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=20170502092552.4d2f96bf@katipo2.lan \
    --to=kentnl@gentoo.org \
    --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