Re: [gentoo-dev] Re: [PATCH 4/4] toolchain-funcs.eclass: Add helpful tc-is-{gcc,clang} wrappers

[Michał Górny]

On Thu, 23 Jun 2016 21:32:34 -0400
Mike Frysinger  wrote:

> On 22 Jun 2016 22:06, Michał Górny wrote:
> > +# @FUNCTION: tc-is-gcc
> > +# @DESCRIPTION:
> > +# Return true if the current compiler is pure GCC.  
> 
> "pure" doesn't make much sense and is just confusing
> 
> shouldn't this be a @RETURN instead of @DESCRIPTION ?  same for clang below.

I've followed suit with other functions in the eclass. They use @RETURN
for stuff that is echoed, and @DESCRIPTION for exit codes.

-- 
Best regards,
Michał Górny



pgpYoLz6et8QV.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Asking for permission to update packages from LINGUAS to L10N

[Daniel Campbell]

On 06/23/2016 02:04 PM, Ulrich Mueller wrote:
> I have created tracker bug https://bugs.gentoo.org/586734 for the
> LINGUAS to L10N conversion, and started to file bugs for individual
> packages. (Starting with lightweight stuff like metapackages, so users
> won't spend too much time with rebuilding if they don't get their L10N
> configuration immediately right.)
> 
> However, it looks like filing bugs for all affected packages is going
> to be tedious. Therefore I am asking for permission to update ebuilds
> for the easy cases directly, e.g. when the change is only a simple
> renaming from linguas_* to l10n_*.
> 
> Please speak up if you don't want your packages to be touched and
> prefer bugs to be filed for them.
> 
> Ulrich
> 
I didn't see any mention of LINGUAS in my ebuilds, but if you stumble
across one, feel free to fix it and ideally let me know, so I can take a
look and understand how it needs to be done.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [PATCH 2/4] toolchain-funcs.eclass: Assume CPP="$(tc-getCC) -E" when unset, #582822

[Mike Frysinger]

OK
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH 1/4] toolchain-funcs.eclass: Fix _tc-getPROG with multi-parameter defaults

[Mike Frysinger]

OK
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH 4/4] toolchain-funcs.eclass: Add helpful tc-is-{gcc,clang} wrappers

[Mike Frysinger]

On 22 Jun 2016 22:06, Michał Górny wrote:
> +# @FUNCTION: tc-is-gcc
> +# @DESCRIPTION:
> +# Return true if the current compiler is pure GCC.

"pure" doesn't make much sense and is just confusing

shouldn't this be a @RETURN instead of @DESCRIPTION ?  same for clang below.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Asking for permission to update packages from LINGUAS to L10N

[Ulrich Mueller]

I have created tracker bug https://bugs.gentoo.org/586734 for the
LINGUAS to L10N conversion, and started to file bugs for individual
packages. (Starting with lightweight stuff like metapackages, so users
won't spend too much time with rebuilding if they don't get their L10N
configuration immediately right.)

However, it looks like filing bugs for all affected packages is going
to be tedious. Therefore I am asking for permission to update ebuilds
for the easy cases directly, e.g. when the change is only a simple
renaming from linguas_* to l10n_*.

Please speak up if you don't want your packages to be touched and
prefer bugs to be filed for them.

Ulrich


pgpqBgx1yb3gq.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Make EGIT_LIVE_* associative arrays

[Michał Górny]

On Thu, 23 Jun 2016 14:28:39 -0500
Dan Douglas  wrote:

> On 06/23/2016 01:48 PM, Michał Górny wrote:
> > It would be best if we could kill the old way but I doubt it's a good idea 
> > right now.  
> 
> Yeah I was sad when I realized a nice naming scheme just barely
> wasn't going to work thanks to EGIT_LIVE_REPO_URI being shortened to
> EGIT_LIVE_REPO, but I didn't want to break it.
> 
> The other thing is the associative arrays not being exportable so if we
> want something that can work for interactive use / make.conf / package.env
> then we almost need both.
> 
> > One request though: don't use PN but CATEGORY/PN.  
> 
> True. I wasn't sure just how far to go with it. If you really wanted
> to go all-out I could split arbitrary atoms with versionator and figure out a
> custom lookup function to match up keys-values... but ugh. I'll just do
> CATEGORY/PN for now. :)

Well, just to be clear I don't like that magic either. However, I
wanted to preserve it for compatibility with old git-2 eclass, i.e. so
that when ebuilds are updated from git-2 to git-r3 people's overrides
won't suddenly stop working.

Originally I just wanted to expect people to override EGIT_REPO_URI via
package.env but that won't work since ebuilds would override it.

-- 
Best regards,
Michał Górny



pgpRfL6c10vZY.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Make EGIT_LIVE_* associative arrays

[Ulrich Mueller]

> On Thu, 23 Jun 2016, Dan Douglas wrote:

>> That's the wrong way around. You should keep the EAPI version check
>> but drop the check for the bash version.

> I don't think that will work. You don't want this to vary by EAPI.

Much less you want it to vary within a single EAPI, depending on
package versions installed by the user.

PMS defines the bash version for each EAPI for a reason. The spec even
says that the shell's compatibility level should be set to the exact
version specified if possible, so the intent is clear. Namely, ebuilds
and eclasses are expected to stick to the features available in that
bash version. Especially, they should not try to outsmart the spec by
sniffing for the version of the shell themselves.

> That aside, these variables are documented as being for
> configuration and not part of the API for inheriting code.

That sounds like the cleanest solution would be a git-r4 eclass
supporting only EAPI 6 (or later).

Ulrich


pgp0P5S9curUb.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Make EGIT_LIVE_* associative arrays

[Dan Douglas]

On 06/23/2016 01:48 PM, Michał Górny wrote:
> It would be best if we could kill the old way but I doubt it's a good idea 
> right now.

Yeah I was sad when I realized a nice naming scheme just barely
wasn't going to work thanks to EGIT_LIVE_REPO_URI being shortened to
EGIT_LIVE_REPO, but I didn't want to break it.

The other thing is the associative arrays not being exportable so if we
want something that can work for interactive use / make.conf / package.env
then we almost need both.

> One request though: don't use PN but CATEGORY/PN.

True. I wasn't sure just how far to go with it. If you really wanted
to go all-out I could split arbitrary atoms with versionator and figure out a
custom lookup function to match up keys-values... but ugh. I'll just do
CATEGORY/PN for now. :)

(There's a branch for this here for reference):
https://github.com/ormaaj/gentoo/blob/git-r3-live-arrays/eclass/git-r3.eclass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Make EGIT_LIVE_* associative arrays

[Dan Douglas]

On 06/23/2016 09:15 AM, Ulrich Mueller wrote:
>> On Thu, 23 Jun 2016, Dan Douglas wrote:
>
>> Well I just dropped the EAPI check since it was pointless anyway.
>
>> https://github.com/gentoo/gentoo/pull/1723/commits/3ebc1f57378a5ed4a62232ac87a0955ccdd33a4d
>
> That's the wrong way around. You should keep the EAPI version check
> but drop the check for the bash version.

I don't think that will work. You don't want this to vary by EAPI. For instance
I was using this for merging a set and wanted all of its packages to check out a
particular tag without having to care about which EAPI is used by each package.
All that matters is that it's consistent system-wide.

> PMS clearly defines the bash
> version for each EAPI (namely, bash-3.2 for EAPI 0 to 5 and bash-4.2
> for EAPI 6).

Ok. FWIW this is valid bash 3 and 4 code. I don't think it's so clear what that
means for eclass shared code.

The API exposed here is still invariant. It's typically the responsibility of
the calling code to know whether the current environment supports a particular
datatype before attempting to use it, and not a requirement for library code to
refuse handling that type (like through some ad-hoc polymorphism) when
requested unless doing so would somehow break backwards-compatibility.

That aside, these variables are documented as being for configuration and not
part of the API for inheriting code.

I won't fight too hard if you really hate this, but the previous ${PN}_var is
pretty ugly. The `s/[+-]/_/` name mangling rule wasn't even documented, which
was what got me looking at this code in the first place.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Make EGIT_LIVE_* associative arrays

[Michał Górny]

On Wed, 22 Jun 2016 18:22:38 -0500
Dan Douglas  wrote:

> This creates new associative arrays for each "live" variable if bash4 /
> eapi6 is available. Mainly for user convenience in a bashrc as an
> alternative to magic variable names.
> ---
>  eclass/git-r3.eclass | 68 
> ++--
>  1 file changed, 39 insertions(+), 29 deletions(-)

My first thought was: no, thanks, no more complexity. But after some
thinking, I guess this may actually be better. It would be best if we
could kill the old way but I doubt it's a good idea right now.

Before giving you the final answer/review, I'm going to wait a while to
see what others think. In the meantime, you could also think if this
could be extended to support overrides on direct git-r3_fetch calls,
i.e. when ebuild fetches multiple repos.

My first thought would be to use original repo URI as the key instead
of PN. Or maybe support both, i.e. PN for global override and URI for
in-fetch override.

One request though: don't use PN but CATEGORY/PN.

-- 
Best regards,
Michał Górny



pgpGZ3dhKQT5g.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Make EGIT_LIVE_* associative arrays

[Ulrich Mueller]

> On Thu, 23 Jun 2016, Dan Douglas wrote:

> Well I just dropped the EAPI check since it was pointless anyway.

> https://github.com/gentoo/gentoo/pull/1723/commits/3ebc1f57378a5ed4a62232ac87a0955ccdd33a4d

That's the wrong way around. You should keep the EAPI version check
but drop the check for the bash version. PMS clearly defines the bash
version for each EAPI (namely, bash-3.2 for EAPI 0 to 5 and bash-4.2
for EAPI 6).

Ulrich


pgpAmqloOslx6.pgp
Description: PGP signature

[gentoo-dev] Last rites: media-video/subotage

[Michał Górny]

# Michał Górny  (23 Jun 2016)
# Integrated in media-video/bashnapi. Removal in 30 days.
media-video/subotage

-- 
Best regards,
Michał Górny



pgpqJ29JgxwVQ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Make EGIT_LIVE_* associative arrays

[Dan Douglas]

On 06/22/2016 09:56 PM, Michael Orlitzky wrote:
> On 06/22/2016 08:34 PM, Dan Douglas wrote:
>> On 06/22/2016 07:12 PM, Ulrich Mueller wrote:
 On Wed, 22 Jun 2016, Dan Douglas wrote:
>>>
 +  [[
 +  ( BASH_VERSINFO[0] -ge 4 || EAPI -ge 6 ) &&
 +  $(declare -p "EGIT_${livevars[idx+1]}" 2>/dev/null) == 
 'declare -A'*
 +  ]] && ref=EGIT_${livevars[idx+1]}[\$PN]
>>>
>>> EAPI is not a number but a string, so don't use arithmetic comparison
>>> to test for it
>>
>> You mean in the future it may have non-digit values that pass the
>> `case $EAPI in ...)` at the top?
> 
> Yeah, it would be perfectly legal to name the next EAPI "seven" and add
> it to the case statement at the top. Then [[ "seven" -ge 6 ]] is false.
> 

Oh fun, thanks.

Well I just dropped the EAPI check since it was pointless anyway.

https://github.com/gentoo/gentoo/pull/1723/commits/3ebc1f57378a5ed4a62232ac87a0955ccdd33a4d



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 2/2] toolchain-funcs.eclass: Add helpful tc-is-{gcc,clang} wrappers

[Michał Górny]

---
 eclass/tests/toolchain-funcs.sh | 28 
 eclass/toolchain-funcs.eclass   | 14 ++
 2 files changed, 42 insertions(+)

diff --git a/eclass/tests/toolchain-funcs.sh b/eclass/tests/toolchain-funcs.sh
index 0b9b7d7..d86eee4 100755
--- a/eclass/tests/toolchain-funcs.sh
+++ b/eclass/tests/toolchain-funcs.sh
@@ -118,6 +118,20 @@ export CC=gcc
 )
 tend $?
 
+tbegin "tc-is-gcc (gcc)"
+(
+export CC=gcc
+tc-is-gcc
+)
+tend $?
+
+tbegin "! tc-is-clang (gcc)"
+(
+export CC=gcc
+! tc-is-clang
+)
+tend $?
+
 if type -P clang &>/dev/null; then
tbegin "tc-get-compiler-type (clang)"
(
@@ -125,6 +139,20 @@ if type -P clang &>/dev/null; then
[[ $(tc-get-compiler-type) == clang ]]
)
tend $?
+
+   tbegin "! tc-is-gcc (clang)"
+   (
+   export CC=clang
+   ! tc-is-gcc
+   )
+   tend $?
+
+   tbegin "tc-is-clang (clang)"
+   (
+   export CC=clang
+   tc-is-clang
+   )
+   tend $?
 fi
 
 texit
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 4a45f78..67eab38 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -604,6 +604,20 @@ tc-get-compiler-type() {
esac
 }
 
+# @FUNCTION: tc-is-gcc
+# @DESCRIPTION:
+# Return true if the current compiler is pure GCC.
+tc-is-gcc() {
+   [[ $(tc-get-compiler-type) == gcc ]]
+}
+
+# @FUNCTION: tc-is-clang
+# @DESCRIPTION:
+# Return true if the current compiler is clang.
+tc-is-clang() {
+   [[ $(tc-get-compiler-type) == clang ]]
+}
+
 # Internal func.  The first argument is the version info to expand.
 # Query the preprocessor to improve compatibility across different
 # compilers rather than maintaining a --version flag matrix. #335943
-- 
2.9.0

[gentoo-dev] [PATCH 0/2] v3: tc-get-compiler-type() & wrappers

[Michał Górny]

A quick update of patches 3/4.

Changes:

a. the logic in tc-get-compiler-type() has been moved to cpp to make
   the bash side simpler and less likely to break,

b. added tests for tc-is-* wrappers.

Michał Górny (2):
  toolchain-funcs.eclass: Add tc-get-compiler-type()
  toolchain-funcs.eclass: Add helpful tc-is-{gcc,clang} wrappers

 eclass/tests/toolchain-funcs.sh | 43 +
 eclass/toolchain-funcs.eclass   | 33 +++
 2 files changed, 76 insertions(+)

-- 
2.9.0

[gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: Add tc-get-compiler-type()

[Michał Górny]

Add a tc-get-compiler-type() function that can be used to identify
the compiler being used, using the preprocessor defines. Alike
gcc-*version() routines, it uses CPP (which in turn uses CC).

The major usage would be applying compiler-specific quirks and limiting
gcc version checks to compilers that actually are gcc, since e.g. clang
reports gcc version 4.2 -- which would incorrectly cause numerous gcc
version checks in ebuilds to fail.
---
 eclass/tests/toolchain-funcs.sh | 15 +++
 eclass/toolchain-funcs.eclass   | 19 +++
 2 files changed, 34 insertions(+)

diff --git a/eclass/tests/toolchain-funcs.sh b/eclass/tests/toolchain-funcs.sh
index 41c1ae5..0b9b7d7 100755
--- a/eclass/tests/toolchain-funcs.sh
+++ b/eclass/tests/toolchain-funcs.sh
@@ -111,5 +111,20 @@ tc-ld-disable-gold
 )
 tend $?
 
+tbegin "tc-get-compiler-type (gcc)"
+(
+export CC=gcc
+[[ $(tc-get-compiler-type) == gcc ]]
+)
+tend $?
+
+if type -P clang &>/dev/null; then
+   tbegin "tc-get-compiler-type (clang)"
+   (
+   export CC=clang
+   [[ $(tc-get-compiler-type) == clang ]]
+   )
+   tend $?
+fi
 
 texit
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 3398775..4a45f78 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -585,6 +585,25 @@ tc-endian() {
esac
 }
 
+# @FUNCTION: tc-get-compiler-type
+# @RETURN: keyword identifying the compiler: gcc, clang, unknown
+tc-get-compiler-type() {
+   local code='
+#if defined(__clang__)
+   HAVE_CLANG
+#elif defined(__GNUC__)
+   HAVE_GCC
+#endif
+'
+   local res=$($(tc-getCPP "$@") -E -P - <<<"${code}")
+
+   case ${res} in
+   *HAVE_CLANG*)   echo clang;;
+   *HAVE_GCC*) echo gcc;;
+   *)  echo unknown;;
+   esac
+}
+
 # Internal func.  The first argument is the version info to expand.
 # Query the preprocessor to improve compatibility across different
 # compilers rather than maintaining a --version flag matrix. #335943
-- 
2.9.0

Re: [gentoo-dev] [PATCH 3/4] toolchain-funcs.eclass: Add tc-get-compiler-type()

[Michał Górny]

On Thu, 23 Jun 2016 08:52:20 +0200
Fabian Groffen  wrote:

> On 22-06-2016 22:06:53 +0200, Michał Górny wrote:
> > +# @FUNCTION: tc-get-compiler-type
> > +# @RETURN: keyword identifying the compiler: gcc, clang, unknown
> > +tc-get-compiler-type() {
> > +   set -- $($(tc-getCPP "$@") -E -P - <<<"CPP_WORKS __GNUC__ __clang__")  
> 
> % echo "CPP_WORKS __GNUC__ __clang__" | clang -E -P  - 
> CPP_WORKS 4 1
> 
> The logic below does the right thing, but it might be good for future
> reference to make note of this (clang).

I'm actually thinking of moving the whole logic into cpp using '#if
defined', and just matching the output for the result. This would be
easier to maintain in the future, I guess.

> > +
> > +   # CPP_WORKS shouldn't be substituted -- so if it's not there,
> > +   # cpp is probably broken
> > +   if [[ $1 != CPP_WORKS ]]; then
> > +   echo unknown
> > +   # Check which of the defines were substituted
> > +   elif [[ $3 != __clang__ ]]; then
> > +   echo clang
> > +   elif [[ $2 != __GNUC__ ]]; then
> > +   echo gcc
> > +   else
> > +   echo unknown
> > +   fi
> > +}  
> 



-- 
Best regards,
Michał Górny



pgpD0aKTNB_ve.pgp
Description: OpenPGP digital signature