Re: [gentoo-dev] [PATCH] gradle.eclass: add new eclass
On 2023-01-06 18:20, Florian Schmaus wrote:
> Signed-off-by: Florian Schmaus
> ---
> eclass/gradle.eclass | 149 +
> eclass/tests/gradle.sh | 62 +
> 2 files changed, 211 insertions(+)
> create mode 100644 eclass/gradle.eclass
> create mode 100755 eclass/tests/gradle.sh
>
> diff --git a/eclass/gradle.eclass b/eclass/gradle.eclass
> new file mode 100644
> index ..a321262612d0
> --- /dev/null
> +++ b/eclass/gradle.eclass
> @@ -0,0 +1,149 @@
> +# Copyright 2021-2023 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: gradle.eclass
I think "gradle-utils" is a better name since the eclass does not export
any phase functions or set metadata variables (this should be noted in
the description btw).
> +# @MAINTAINER:
> +# Gentoo Java Project
> +# @AUTHOR:
> +# Florian Schmaus
> +# @BLURB: Utility functions for the gradle build system.
First letter should not be capitalized (for manpage reasons).
> +# @DESCRIPTION:
> +# Utility functions for the gradle build system.
Either drop description or don't repeat blurb here.
> +
> +case ${EAPI} in
> + 7|8) ;;
> + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> +esac
> +
> +if [[ -z ${_GRADLE_ECLASS} ]] ; then
> +_GRADLE_ECLASS=1
> +
> +inherit edo
> +
> +# @ECLASS_VARIABLE: EGRADLE_MIN
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Minimum required gradle version.
> +
> +# @ECLASS_VARIABLE: EGRADLE_MAX_EXCLUSIVE
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# First gradle version that is not supported.
> +
> +# @ECLASS_VARIABLE: EGRADLE_EXACT_VER
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# The exact required gradle version.
> +
> +# @ECLASS_VARIABLE: EGRADLE_PARALLEL
> +# @DESCRIPTION:
> +# Set to the 'true', the default, to invoke gradle with --parallel. Set
> +# to 'false' to disable parallel gradle builds.
> +: "${EGRADLE_PARALLEL=true}"
Can be deduced indeirectly (when "makeopts_jobs" equals to 1).
> +
> +# @ECLASS_VARIABLE: EGRADLE_USER_HOME
> +# @DESCRIPTION:
> +# Directroy used as the user's home directory by gradle. Defaults to
> +# ${T}/gradle_user_home
> +: "${EGRADLE_USER_HOME="${T}/gradle_user_home"}"
Can it be just ${HOME}?
> +
> +# @ECLASS_VARIABLE: EGRADLE_OVERWRITE
> +# @USER_VARIABLE
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# User-specified overwrite of the used gradle binary.
> +
> +# @FUNCTION: gradle-set_EGRADLE
> +# @DESCRIPTION:
> +# Set the EGRADLE environment variable.
> +gradle-set_EGRADLE() {
> + [[ -n ${EGRADLE} ]] && return
> +
> + if [[ -n ${EGRADLE_OVERWRITE} ]]; then
> + export EGRADLE="${EGRADLE_OVERWRITE}"
Any reason to export?
> + return
> + fi
> +
> + local candidates candidate selected selected_ver
> +
> + candidates=$(compgen -c gradle-)
> + for candidate in ${candidates}; do
> + if [[ ! ${candidate} =~ gradle(-bin)?-([.0-9]+) ]]; then
> + continue
> + fi
> +
> + local ver
> + if (( ${#BASH_REMATCH[@]} == 3 )); then
> + ver="${BASH_REMATCH[2]}"
> + else
> + ver="${BASH_REMATCH[1]}"
> + fi
> +
> + if [[ -n ${EGRADLE_EXACT_VER} ]]; then
> + ver_test "${ver}" -ne "${EGRADLE_EXACT_VER}" && continue
> +
> + selected="${candidate}"
> + selected_ver="${ver}"
> + break
> + fi
> +
> + if [[ -n ${EGRADLE_MIN} ]] \
> +&& ver_test "${ver}" -lt "${EGRADLE_MIN}"; then
> + # Candidate does not satisfy EGRADLE_MIN condition.
> + continue
> + fi
> +
> + if [[ -n ${EGRADLE_MAX_EXCLUSIVE} ]] \
> +&& ver_test "${ver}" -ge "${EGRADLE_MAX_EXCLUSIVE}";
> then
> + # Candidate does not satisfy EGRADLE_MAX_EXCLUSIVE
> condition.
> + continue
> + fi
> +
> + if [[ -n ${selected_ver} ]] \
> +&& ver_test "${selected_ver}" -gt "${ver}"; then
> + # Candidate is older than the currently selected
> candidate.
> + continue
> + fi
> +
> + selected="${candidate}"
> + selected_ver="${ver}"
> + done
> +
> + if [[ -z ${selected} ]]; then
> + die "Could not find (suitable) gradle installation in PATH"
> + fi
> +
> + export EGRADLE="${selected}"
> + export EGRADLE_VER="${ver}"
> +}
> +
> +# @FUNCTION: egradle
> +# @USAGE: [gradle-args]
> +# @DESCRIPTION:
> +# Invoke gradle with the optionally provided arguments.
> +egradle() {
> + gradle-set_EGRADLE
> +
> + local gradle_args=(
> + --console=plain
> + --info
> + --stacktrace
> + --no-daemon
> + --offline
> +
Re: [gentoo-dev] [PATCH] gradle.eclass: add new eclass
> On 6 Jan 2023, at 17:20, Florian Schmaus wrote: > > Signed-off-by: Florian Schmaus > --- > eclass/gradle.eclass | 149 + > eclass/tests/gradle.sh | 62 + > 2 files changed, 211 insertions(+) > create mode 100644 eclass/gradle.eclass > create mode 100755 eclass/tests/gradle.sh > > diff --git a/eclass/gradle.eclass b/eclass/gradle.eclass > [...] > + > +# @ECLASS_VARIABLE: EGRADLE_MIN > +# @DEFAULT_UNSET > +# @DESCRIPTION: > +# Minimum required gradle version. > + > +# @ECLASS_VARIABLE: EGRADLE_MAX_EXCLUSIVE > +# @DEFAULT_UNSET > +# @DESCRIPTION: > +# First gradle version that is not supported. > + > +# @ECLASS_VARIABLE: EGRADLE_EXACT_VER > +# @DEFAULT_UNSET > +# @DESCRIPTION: > +# The exact required gradle version. > + It feels a pity to not use the now-somewhat standard PYTHON_COMPAT/LUA_COMPAT-style API. Is there a reason not to? If it doesn't fit how Gradle versioning works / the number of targets is likely to be far too high, It's fine as-is. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] RFC: new gradle.eclass
On 06/01/2023 19.52, Yuan Liao (Leo) wrote:
While I warmly appreciate and welcome any effort to improve support
for Java build systems on Gentoo, I also wonder what functionality
ebuild authors who are creating a Java package might expect from an
eclass called "gradle.eclass".
It is not strictly forbidden for an eclass to serve multiple use cases.
However, there is an argument to separate the concerns into different
eclasses (as we do already with other ecosystems). But we don't have
those different concerns implemented right now. And there is IMHO a good
reason this eclass should be called gradle.eclass: it provides basic
functionality to discover a suitable gradle version and invoke gradle
with sane defaults and in the idiomatic Gentoo way ("egradle ").
I'm not doubting this eclass's usefulness -- to me, it looks like a
convenient eclass when a Gradle project's dependencies are vendored
and included in SRC_URI.
The PR I mentioned migrates an openjfx ebuild from using its own gradle
installation to the eclass [1]. And ::java has a ghidra ebuild [2] that
uses gradle.eclass. Which was based on ::pentoo's ghidra ebuild with
minor modifications to use the eclass. I recommend to look at the diff
between the ::java version and ::pentoo version of the ghidra ebuild too.
And the eclass, as is, is currently not only used for sideloaded
dependencies. If you look at the openjfx ebuild then you will find that
it consumes java libraries that are installed as Gentoo package
(stringtemplate and hamcrest-core) and injects it into the Gradle build.
Specialized eclasses are totally fine as
we've already got plenty of them in the tree. But I think what an
average Java ebuild author often wants is an eclass with which they
can just declare all dependencies of the Gradle project in *DEPEND
variables, and rely on the default pkg_* and src_* functions from the
eclass to do the rest, with no or only minimal overrides necessary.
They might trust the eclass to introduce any Java dependencies
installed by Portage to Gradle, invoke the build system, and finally
install the JARs built.
Yeah, that is what I also would prefer. And, in fact, this is done for
many existing Java ebuilds. However, reality is that it is often not
feasible to do so with modern Java build systems, as they switch from
consuming Jar files to consuming Maven artifacts with POMs. I'd love to
see an effort to remedy the situation and I actually believe the
gradle.eclass provides basic functionality towards this, but the cruel
reality is that we are far away from that (as far as I can tell) and
currently do not have the manpower to make it happen. I would be happy
to be proven wrong, though.
Furthermore, the approach that the openjfx ebuild uses to inject
libraries in the Gradle build is not generally applicable. IMHO the
perfect solution would consists of a system-wide Maven repository, where
Java ebuilds install their Jar files. And a robust way to tell Gradle
(and Maven, …) to consume artifacts from such a system-wide Maven
repository and a way to tell the build system to not perform any network
activity.
I think thin would be beneficial not only to Gentoo, but to other
distributions too. But, again, it is a long way to get there.
Maybe we will be lucky enough to have such an eclass in the future.
But should we add a remark to the eclass's description to warn that
this might not be the generalized "gradle.eclass" suitable for
packaging most Gradle-based projects, if that is what people would
believe a "gradle.eclass" would do for them?
I am not sure what such a warning is going to acomplish. But certainly,
if "better" approaches are implemented, then our documentation should
point them out.
- Flow
1:
https://github.com/gentoo/gentoo/pull/28986/commits/808197948074c1582d3e3c7877d68cb9a6fa2f72
2:
https://github.com/gentoo/java-overlay/blob/master/dev-util/ghidra/ghidra-10.2.2-r2.ebuild
Re: [gentoo-dev] RFC: new gradle.eclass
While I warmly appreciate and welcome any effort to improve support for Java build systems on Gentoo, I also wonder what functionality ebuild authors who are creating a Java package might expect from an eclass called "gradle.eclass". I'm not doubting this eclass's usefulness -- to me, it looks like a convenient eclass when a Gradle project's dependencies are vendored and included in SRC_URI. Specialized eclasses are totally fine as we've already got plenty of them in the tree. But I think what an average Java ebuild author often wants is an eclass with which they can just declare all dependencies of the Gradle project in *DEPEND variables, and rely on the default pkg_* and src_* functions from the eclass to do the rest, with no or only minimal overrides necessary. They might trust the eclass to introduce any Java dependencies installed by Portage to Gradle, invoke the build system, and finally install the JARs built. Maybe we will be lucky enough to have such an eclass in the future. But should we add a remark to the eclass's description to warn that this might not be the generalized "gradle.eclass" suitable for packaging most Gradle-based projects, if that is what people would believe a "gradle.eclass" would do for them? Leo3418 On Fri, Jan 6, 2023 at 9:21 AM Florian Schmaus wrote: > > Happy new year everyone! > > I'd like to as for a review of an initial eclass for gradle. This is my > first eclass, so I am sure there is plenty to find. ;) > > The related github PR is https://github.com/gentoo/gentoo/pull/28986 > > - Flow > >
Re: [gentoo-dev] RFC: new gradle.eclass
Hallelujah! Finally support for Gradle! Thank you so much for taking time to implement it! On 1/6/23 18:20, Florian Schmaus wrote: Happy new year everyone! I'd like to as for a review of an initial eclass for gradle. This is my first eclass, so I am sure there is plenty to find. ;) The related github PR is https://github.com/gentoo/gentoo/pull/28986 - Flow -- Have a great day! ~ Maciej XGQT Barć OpenPGP_0x14D74A1F43A6AC3C.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] gradle.eclass: add new eclass
Signed-off-by: Florian Schmaus
---
eclass/gradle.eclass | 149 +
eclass/tests/gradle.sh | 62 +
2 files changed, 211 insertions(+)
create mode 100644 eclass/gradle.eclass
create mode 100755 eclass/tests/gradle.sh
diff --git a/eclass/gradle.eclass b/eclass/gradle.eclass
new file mode 100644
index ..a321262612d0
--- /dev/null
+++ b/eclass/gradle.eclass
@@ -0,0 +1,149 @@
+# Copyright 2021-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: gradle.eclass
+# @MAINTAINER:
+# Gentoo Java Project
+# @AUTHOR:
+# Florian Schmaus
+# @BLURB: Utility functions for the gradle build system.
+# @DESCRIPTION:
+# Utility functions for the gradle build system.
+
+case ${EAPI} in
+ 7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ -z ${_GRADLE_ECLASS} ]] ; then
+_GRADLE_ECLASS=1
+
+inherit edo
+
+# @ECLASS_VARIABLE: EGRADLE_MIN
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Minimum required gradle version.
+
+# @ECLASS_VARIABLE: EGRADLE_MAX_EXCLUSIVE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# First gradle version that is not supported.
+
+# @ECLASS_VARIABLE: EGRADLE_EXACT_VER
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# The exact required gradle version.
+
+# @ECLASS_VARIABLE: EGRADLE_PARALLEL
+# @DESCRIPTION:
+# Set to the 'true', the default, to invoke gradle with --parallel. Set
+# to 'false' to disable parallel gradle builds.
+: "${EGRADLE_PARALLEL=true}"
+
+# @ECLASS_VARIABLE: EGRADLE_USER_HOME
+# @DESCRIPTION:
+# Directroy used as the user's home directory by gradle. Defaults to
+# ${T}/gradle_user_home
+: "${EGRADLE_USER_HOME="${T}/gradle_user_home"}"
+
+# @ECLASS_VARIABLE: EGRADLE_OVERWRITE
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# User-specified overwrite of the used gradle binary.
+
+# @FUNCTION: gradle-set_EGRADLE
+# @DESCRIPTION:
+# Set the EGRADLE environment variable.
+gradle-set_EGRADLE() {
+ [[ -n ${EGRADLE} ]] && return
+
+ if [[ -n ${EGRADLE_OVERWRITE} ]]; then
+ export EGRADLE="${EGRADLE_OVERWRITE}"
+ return
+ fi
+
+ local candidates candidate selected selected_ver
+
+ candidates=$(compgen -c gradle-)
+ for candidate in ${candidates}; do
+ if [[ ! ${candidate} =~ gradle(-bin)?-([.0-9]+) ]]; then
+ continue
+ fi
+
+ local ver
+ if (( ${#BASH_REMATCH[@]} == 3 )); then
+ ver="${BASH_REMATCH[2]}"
+ else
+ ver="${BASH_REMATCH[1]}"
+ fi
+
+ if [[ -n ${EGRADLE_EXACT_VER} ]]; then
+ ver_test "${ver}" -ne "${EGRADLE_EXACT_VER}" && continue
+
+ selected="${candidate}"
+ selected_ver="${ver}"
+ break
+ fi
+
+ if [[ -n ${EGRADLE_MIN} ]] \
+ && ver_test "${ver}" -lt "${EGRADLE_MIN}"; then
+ # Candidate does not satisfy EGRADLE_MIN condition.
+ continue
+ fi
+
+ if [[ -n ${EGRADLE_MAX_EXCLUSIVE} ]] \
+ && ver_test "${ver}" -ge "${EGRADLE_MAX_EXCLUSIVE}";
then
+ # Candidate does not satisfy EGRADLE_MAX_EXCLUSIVE
condition.
+ continue
+ fi
+
+ if [[ -n ${selected_ver} ]] \
+ && ver_test "${selected_ver}" -gt "${ver}"; then
+ # Candidate is older than the currently selected
candidate.
+ continue
+ fi
+
+ selected="${candidate}"
+ selected_ver="${ver}"
+ done
+
+ if [[ -z ${selected} ]]; then
+ die "Could not find (suitable) gradle installation in PATH"
+ fi
+
+ export EGRADLE="${selected}"
+ export EGRADLE_VER="${ver}"
+}
+
+# @FUNCTION: egradle
+# @USAGE: [gradle-args]
+# @DESCRIPTION:
+# Invoke gradle with the optionally provided arguments.
+egradle() {
+ gradle-set_EGRADLE
+
+ local gradle_args=(
+ --console=plain
+ --info
+ --stacktrace
+ --no-daemon
+ --offline
+ --no-build-cache
+ --gradle-user-home "${EGRADLE_USER_HOME}"
+ --project-cache-dir "${T}/gradle_project_cache"
+ )
+
+ if $EGRADLE_PARALLEL; then
+ gradle_args+=( --parallel )
+ fi
+
+ local -x JAVA_TOOL_OPTIONS="-Duser.home=\"$T\""
+ # TERM needed, otherwise gradle may fail on terms it does not know about
+ TERM=xterm \
+ edo \
+ "${EGRADLE}" "${gradle_args[@]}" "${@}"
+}
+
+fi
diff --git a/eclass/tests/gradle.sh b/eclass/tests/gradle.sh
new file mode 100755
index ..61666c1bc60e
--- /dev/null
+++ b/eclass/tes
[gentoo-dev] RFC: new gradle.eclass
Happy new year everyone! I'd like to as for a review of an initial eclass for gradle. This is my first eclass, so I am sure there is plenty to find. ;) The related github PR is https://github.com/gentoo/gentoo/pull/28986 - Flow
Re: [gentoo-dev] [PATCH v2] distutils-r1.eclass: support nonfatal in test
On Fri, 2023-01-06 at 16:27 +0100, Toralf Förster wrote: > On 1/6/23 01:20, alexey+gen...@asokolov.org wrote: > > If the test fails with "die", Xvfb keeps running forever; but it's > > cleaned up correctly with die -n > > At my tinderbox I do experience sometimes a running dirmngr process > solely running since days. /me wonders if that's the result of a similar > scenario? > Normally it shouldn't be happening since Portage uses PID namespace to kill all leftover processes. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH v2] distutils-r1.eclass: support nonfatal in test
On 1/6/23 01:20, alexey+gen...@asokolov.org wrote: If the test fails with "die", Xvfb keeps running forever; but it's cleaned up correctly with die -n At my tinderbox I do experience sometimes a running dirmngr process solely running since days. /me wonders if that's the result of a similar scenario? -- Toralf PGP 23217DA7 9B888F45 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2] distutils-r1.eclass: support nonfatal in test
On Fri, 2023-01-06 at 00:20 +, alexey+gen...@asokolov.org wrote:
> From: Alexey Sokolov
>
> Rationale:
>
> src_test() {
> virtx distutils-r1_src_test
> }
>
> If the test fails with "die", Xvfb keeps running forever; but it's
> cleaned up correctly with die -n
>
> Signed-off-by: Alexey Sokolov
> ---
> eclass/distutils-r1.eclass | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 371d52bcb7e..8896768d3ce 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2022 Gentoo Authors
> +# Copyright 1999-2023 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: distutils-r1.eclass
> @@ -1559,7 +1559,7 @@ distutils-r1_python_test() {
> esac
>
> if [[ ${?} -ne 0 ]]; then
> - die "Tests failed with ${EPYTHON}"
> + die -n "Tests failed with ${EPYTHON}"
> fi
> }
>
LGTM. I need to think if we have any changes pending.
--
Best regards,
Michał Górny
Re: [gentoo-dev] [PATCH] linux-mod.eclass: Fix MODULESD_* for hyphenated modules (bug #889752)
On 1/4/23 19:06, Patrick McLean wrote:
From: Steven Stallion
Use of the MODULESD__{ADDITIONS,ALIASES,EXAMPLES} variables do not
currently work with external modules that are hyphenated. The current behavior
results in an invalid modprobe.d file containing partially evaluated content.
This appears to be due to use of ${currm} rather than ${currm_t} when
Referencing variables. This changes the use of ${currm} to ${currm_t} when
referencing variables to resolve this issue.
Closes: https://bugs.gentoo.org/889752
---
eclass/linux-mod.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index d14bbf7d9ea..6cf9969b19a 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -408,7 +408,7 @@ generate_modulesd() {
for((t=0; t<${module_aliases}; t++))
do
- echo "alias $(eval echo
\${MODULESD_${currm}_ALIASES[$t]})" \
+ echo "alias $(eval echo
\${MODULESD_${currm_t}_ALIASES[$t]})" \
>> "${module_config}"
done
echo '' >> "${module_config}"
@@ -434,7 +434,7 @@ generate_modulesd() {
fi
#---
- if [[ $(eval echo \${MODULESD_${currm}_ALIASES[0]}) == guess
]]; then
+ if [[ $(eval echo \${MODULESD_${currm_t}_ALIASES[0]}) == guess
]]; then
# So, let's do some guesswork, eh?
if [[ -n ${module_opts} ]]; then
echo "# For Example..." >> "${module_config}"
@@ -449,7 +449,7 @@ generate_modulesd() {
echo "# For Example..." >> "${module_config}"
echo "# --" >> "${module_config}"
for ((t=0; t<${module_examples}; t++)); do
- echo "options $(eval echo
\${MODULESD_${currm}_EXAMPLES[$t]})" \
+ echo "options $(eval echo
\${MODULESD_${currm_t}_EXAMPLES[$t]})" \
>> "${module_config}"
done
echo '' >> "${module_config}"
@@ -458,7 +458,7 @@ generate_modulesd() {
#---
if [[ ${module_additions} -gt 0 ]]; then
for ((t=0; t<${module_additions}; t++)); do
- echo "$(eval echo
\${MODULESD_${currm}_ADDITIONS[$t]})" \
+ echo "$(eval echo
\${MODULESD_${currm_t}_ADDITIONS[$t]})" \
>> "${module_config}"
done
echo '' >> "${module_config}"
Ack
--
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137&op=index
