Re: [gentoo-dev] [PATCH] meson.eclass: add meson_use function

2017-12-16 Thread Jan Chren (rindeal) 
On 15 December 2017 at 17:38, Mike Gilbert  wrote:
> ---
>  eclass/meson.eclass | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 2c943dd6ae27..71735fbfc67d 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -137,6 +137,19 @@ _meson_create_cross_file() {
> EOF
>  }
>
> +# @FUNCTION: meson_use
> +# @USAGE:  [option name]
> +# @DESCRIPTION:
> +# Given a USE flag and meson project option, outputs a string like:
> +#
> +#   -Doption=true
> +#   -Doption=false
> +#
> +# If the project option is unspecified, it defaults to the USE flag.
> +meson_use() {
> +   usex "$1" "-D${2-$1}=true" "-D${2-$1}=false"
> +}
> +
>  # @FUNCTION: meson_src_configure
>  # @DESCRIPTION:
>  # This is the meson_src_configure function.
> --
> 2.15.1
>
>

Isn't this the beginning of this wheel
https://github.com/gentoo/gentoo/commit/e9116b1aebc819a10410960cbb4931aa5e399af1
?

Re: [gentoo-dev] Removal of CVS headers

2017-02-26 Thread Jan Chren (rindeal) 
On 25 February 2017 at 15:05, Ulrich Mueller  wrote:
> As the council has decided in its 2014-10-14 meeting (and confirmed
> again in the 2016-11-13 meeting), CVS headers should be removed after
> the migration to Git. Until recently, this was blocked by repoman
> still checking for the $Id$ line. The latter is now fixed in the
> stable repoman version.
>
> Therefore, I am going to remove the remaining CVS headers throughout
> the tree (except for patches, of course) in two days from now.

Don't forget to clean up wiki and dev docs as well.

Re: [gentoo-dev] RFC: Future EAPI version operator changes

2016-11-06 Thread Jan Chren (rindeal) 
First of all thank you for the research and wish you a good luck in
making the changes happen.


## Reordering to PACKAGE OP VERSION

 [ ] [:]

is more sane than

 [:] [ ]

even though it's not so "hierarchically correct".

Thus instead of writing

dev-foo/bar:4===4.1

one would write

dev-foo/bar==4.1*:4=

which is nicely readable.

But in case the box brackets notation gets incorporated (as in Exheres),

 [:] [[ ]]

is the way to go.


## Version ranges

dev-foo/bar:0[(>=2 && <4) || (>=6 && <10)][baz?]

looks the most promising to me as it allows to include and exclude any
number of ranges.


## Things not included

### Comments/annotations

Currently, there is no way to put inline comments to *DEPEND, IUSE,
..., thus the only supported way is to put the comments above the
specification and somehow tell the reader what part of the
specification is the comment about. For 3-4 deps it's acceptable, for
20+ it's insane and thus no one does it, losing valuable information
about the reasoning by doing so.

Mu current workaround is:

DEPEND_A=(
   # comment
   "cat/pkg..."
   "|| ("
  # comment
  "cat/foo"
  "cat/bar"
   ")"
)
DEPEND="${DEPEND_A[*]}"


### Logical operators for groups

 OR

Currently there is no way to specify:

foo||bar? (
  cat/pkg
)

and one has to copy&paste a lot:

foo? (
  cat/pkg
)
bar? (
  cat/pkg
)

 AND

AND can be specified via nested groups:

foo? (
  bar? (
cat/pkg
  )
)

but this syntax is verbose and not explicit.

foo&&bar? (
  cat/pkg
)

would be much more readable.