Re: [gentoo-dev] [PATCH 2/2] sys-libs/ncurses: Remove parallel econf logic
On 20 Mar 2017 20:35, Michał Górny wrote: > Remove the parallel econf logic that adds a lot of complexity for minor > gain. It results in the output from different configure scripts being > mixed in the build log, making it unreadable. It causes econf to be run > in a subshell which is a PMS violation and can cause issues with some of > package manager implementations. Furthermore, the multijob parallel > processes are interleaved with multilib-build logic which is unsupported > and a very bad idea. NAK. you still haven't backed up your claims wrt to PMS, and this slows things down significantly. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/2] sys-libs/ncurses: Remove parallel econf logic
On Mon, 20 Mar 2017 20:35:52 +0100
Michał Górny wrote:
CCing maintainer
> Remove the parallel econf logic that adds a lot of complexity for minor
> gain. It results in the output from different configure scripts being
> mixed in the build log, making it unreadable. It causes econf to be run
> in a subshell which is a PMS violation and can cause issues with some of
> package manager implementations. Furthermore, the multijob parallel
> processes are interleaved with multilib-build logic which is unsupported
> and a very bad idea.
> ---
> sys-libs/ncurses/ncurses-5.9-r101.ebuild | 11 ---
> sys-libs/ncurses/ncurses-6.0-r1.ebuild | 9 +++--
> 2 files changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/sys-libs/ncurses/ncurses-5.9-r101.ebuild
> b/sys-libs/ncurses/ncurses-5.9-r101.ebuild
> index 76b8a76d3a72..c722d68f3208 100644
> --- a/sys-libs/ncurses/ncurses-5.9-r101.ebuild
> +++ b/sys-libs/ncurses/ncurses-5.9-r101.ebuild
> @@ -1,11 +1,11 @@
> -# Copyright 1999-2015 Gentoo Foundation
> +# Copyright 1999-2017 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
>
> # This version is just for the ABI .5 library
>
> EAPI="5"
>
> -inherit eutils toolchain-funcs multilib-minimal multiprocessing
> +inherit eutils toolchain-funcs multilib-minimal
>
> MY_PV=${PV:0:3}
> MY_P=${PN}-${MY_PV}
> @@ -55,8 +55,6 @@ src_configure() {
> $(usex unicode 'ncursesw' '')
> )
>
> - multijob_init
> -
> # When installing ncurses, we have to use a compatible version of tic.
> # This comes up when cross-compiling, doing multilib builds, upgrading,
> # or installing for the first time. Build a local copy of tic whenever
> @@ -69,16 +67,15 @@ src_configure() {
> CXXFLAGS=${BUILD_CXXFLAGS} \
> CPPFLAGS=${BUILD_CPPFLAGS} \
> LDFLAGS="${BUILD_LDFLAGS} -static" \
> - multijob_child_init do_configure cross --without-shared
> --with-normal
> + do_configure cross --without-shared --with-normal
> fi
> multilib-minimal_src_configure
> - multijob_finish
> }
>
> multilib_src_configure() {
> local t
> for t in "${NCURSES_TARGETS[@]}" ; do
> - multijob_child_init do_configure "${t}"
> + do_configure "${t}"
> done
> }
>
> diff --git a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> index 2ab63de41d4c..d98b23afb751 100644
> --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> @@ -3,7 +3,7 @@
>
> EAPI="5"
>
> -inherit eutils flag-o-matic toolchain-funcs multilib-minimal multiprocessing
> +inherit eutils flag-o-matic toolchain-funcs multilib-minimal
>
> MY_PV=${PV:0:3}
> PV_SNAP=${PV:4}
> @@ -61,8 +61,6 @@ src_configure() {
> $(use unicode && usex threads 'ncursestw' '')
> )
>
> - multijob_init
> -
> # When installing ncurses, we have to use a compatible version of tic.
> # This comes up when cross-compiling, doing multilib builds, upgrading,
> # or installing for the first time. Build a local copy of tic whenever
> @@ -87,16 +85,15 @@ src_configure() {
> CXXFLAGS=${BUILD_CXXFLAGS} \
> CPPFLAGS=${BUILD_CPPFLAGS} \
> LDFLAGS="${BUILD_LDFLAGS} ${lbuildflags}" \
> - multijob_child_init do_configure cross --without-shared
> --with-normal
> + do_configure cross --without-shared --with-normal
> fi
> multilib-minimal_src_configure
> - multijob_finish
> }
>
> multilib_src_configure() {
> local t
> for t in "${NCURSES_TARGETS[@]}" ; do
> - multijob_child_init do_configure "${t}"
> + do_configure "${t}"
> done
> }
>
> --
> 2.12.0
>
>
--
Sergei
pgpOGvl6uhfxk.pgp
Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] [PATCH 1/2] dev-lang/jimtcl: Remove parallel econf code
On Mon, 20 Mar 2017 20:35:51 +0100
Michał Górny wrote:
CCing maintainer
> The parallel econf code is used only with USE=static-libs, and even in
> that case provides negligible speed gain. At the same time, it adds
> a lot of complexity, causes the build logs to be unreadable mix of
> output from both configure scripts and violates PMS by calling econf
> in parallel which can cause issues with different package managers.
> ---
> dev-lang/jimtcl/jimtcl-0.75-r1.ebuild | 10 --
> dev-lang/jimtcl/jimtcl-0.76.ebuild| 10 --
> dev-lang/jimtcl/jimtcl-.ebuild| 10 --
> 3 files changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/dev-lang/jimtcl/jimtcl-0.75-r1.ebuild
> b/dev-lang/jimtcl/jimtcl-0.75-r1.ebuild
> index d05b5040644f..180745bbe7da 100644
> --- a/dev-lang/jimtcl/jimtcl-0.75-r1.ebuild
> +++ b/dev-lang/jimtcl/jimtcl-0.75-r1.ebuild
> @@ -1,9 +1,9 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2017 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
>
> EAPI="5"
>
> -inherit multiprocessing eutils
> +inherit eutils
>
> if [[ ${PV} == "" ]] ; then
> EGIT_REPO_URI="http://repo.or.cz/r/jimtcl.git";
> @@ -40,15 +40,13 @@ src_prepare() {
> }
>
> src_configure() {
> - multijob_init
> - CCACHE=None multijob_child_init econf --with-jim-shared
> + CCACHE=None econf --with-jim-shared
> if use static-libs ; then
> # The build does not support doing both simultaneously.
> mkdir static-libs
> cd static-libs
> - CCACHE=None ECONF_SOURCE=${S} multijob_child_init econf
> + CCACHE=None ECONF_SOURCE=${S} econf
> fi
> - multijob_finish
> }
>
> src_compile() {
> diff --git a/dev-lang/jimtcl/jimtcl-0.76.ebuild
> b/dev-lang/jimtcl/jimtcl-0.76.ebuild
> index a82e24c9b204..ecdcdc96fac5 100644
> --- a/dev-lang/jimtcl/jimtcl-0.76.ebuild
> +++ b/dev-lang/jimtcl/jimtcl-0.76.ebuild
> @@ -1,9 +1,9 @@
> -# Copyright 1999-2015 Gentoo Foundation
> +# Copyright 1999-2017 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
>
> EAPI="5"
>
> -inherit multiprocessing eutils
> +inherit eutils
>
> if [[ ${PV} == "" ]] ; then
> EGIT_REPO_URI="http://repo.or.cz/r/jimtcl.git";
> @@ -40,15 +40,13 @@ src_prepare() {
> }
>
> src_configure() {
> - multijob_init
> - CCACHE=None multijob_child_init econf --with-jim-shared
> + CCACHE=None econf --with-jim-shared
> if use static-libs ; then
> # The build does not support doing both simultaneously.
> mkdir static-libs
> cd static-libs
> - CCACHE=None ECONF_SOURCE=${S} multijob_child_init econf
> + CCACHE=None ECONF_SOURCE=${S} econf
> fi
> - multijob_finish
> }
>
> src_compile() {
> diff --git a/dev-lang/jimtcl/jimtcl-.ebuild
> b/dev-lang/jimtcl/jimtcl-.ebuild
> index d05b5040644f..180745bbe7da 100644
> --- a/dev-lang/jimtcl/jimtcl-.ebuild
> +++ b/dev-lang/jimtcl/jimtcl-.ebuild
> @@ -1,9 +1,9 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2017 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
>
> EAPI="5"
>
> -inherit multiprocessing eutils
> +inherit eutils
>
> if [[ ${PV} == "" ]] ; then
> EGIT_REPO_URI="http://repo.or.cz/r/jimtcl.git";
> @@ -40,15 +40,13 @@ src_prepare() {
> }
>
> src_configure() {
> - multijob_init
> - CCACHE=None multijob_child_init econf --with-jim-shared
> + CCACHE=None econf --with-jim-shared
> if use static-libs ; then
> # The build does not support doing both simultaneously.
> mkdir static-libs
> cd static-libs
> - CCACHE=None ECONF_SOURCE=${S} multijob_child_init econf
> + CCACHE=None ECONF_SOURCE=${S} econf
> fi
> - multijob_finish
> }
>
> src_compile() {
> --
> 2.12.0
>
>
--
Sergei
pgpE6yr0IRD_E.pgp
Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Mon, 20 Mar 2017 22:19:16 +0100 Michał Górny wrote: > On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote: > > On Mon, 20 Mar 2017 19:24:58 +0100 > > Michał Górny wrote: > > > > > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote: > > > > What makes me wonder more are the proposed solutions: So far the > > > > only proposals I've seen are either inlining *all* the code or > > > > moving *all* the code into an eclass. Having a quick look at > > > > autoconf, it seems to me an intermediate solution would work > > > > perfectly fine for the above goals/rules: Put main.eblit into an > > > > eclass. The loading code then would access $FILESDIR only in > > > > src_* phases. This would likely work better for all parties and > > > > would allow to focus on better specifying this gray area of PMS > > > > instead. > > > > > > Don't you find it a bad hypocritical that at the same time you > > > oppose committing an eclass for a single package and you support > > > committing an eclass to support half-working hack for a single > > > package? > > > > First, I don't oppose committing an eclass for a single package, I > > consider it out of scope of eclasses, that's all. > > > > But even if I had stronger positions, this one looks like a win-win > > situation to me: From a code reuse POV, it is an aberration to have > > packages reinvent eblit include logic, each of them having or having > > had its different flaws. Still from a code reuse POV, the eclass > > being able to export functions would reduce ebuild boilerplate > > code, an eblit eclass could test the presence of eblit code and > > call default if absent. From a QA POV, eblit functions can die > > horribly if called outside of src_* phases, ensuring PMS > > assumptions hold and making everyone happy. > > From a code reuse POV, it is an aberration to have an eclass that > reinvents eclass include logic, having or having had flaws. Still from > a code reuse POV, the package manager being able to export functions > would reduce eclass boilterplate code, a package manager could look > for EXPORT_FUNCTIONS and call default if absent. From a QA POV, > eclass can work properly if called outside of src_* phases, ensuring > PMS assumptions hold and making everyone happy. > > ...oh wait, we already have that! Since you still seem to fail to understand the difference, there's nothing I can do for you there. Feel free to convince maintainers, get them kicked if you fail to persuade them, or fork gentoo if you can't get them kicked. Nice team work.
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote: > On Mon, 20 Mar 2017 19:24:58 +0100 > Michał Górny wrote: > > > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote: > > > What makes me wonder more are the proposed solutions: So far the > > > only proposals I've seen are either inlining *all* the code or > > > moving *all* the code into an eclass. Having a quick look at > > > autoconf, it seems to me an intermediate solution would work > > > perfectly fine for the above goals/rules: Put main.eblit into an > > > eclass. The loading code then would access $FILESDIR only in src_* > > > phases. This would likely work better for all parties and would > > > allow to focus on better specifying this gray area of PMS instead. > > > > Don't you find it a bad hypocritical that at the same time you oppose > > committing an eclass for a single package and you support committing > > an eclass to support half-working hack for a single package? > > > > First, I don't oppose committing an eclass for a single package, I > consider it out of scope of eclasses, that's all. > > But even if I had stronger positions, this one looks like a win-win > situation to me: From a code reuse POV, it is an aberration to have > packages reinvent eblit include logic, each of them having or having > had its different flaws. Still from a code reuse POV, the eclass being > able to export functions would reduce ebuild boilerplate code, an > eblit eclass could test the presence of eblit code and call default if > absent. From a QA POV, eblit functions can die horribly if called > outside of src_* phases, ensuring PMS assumptions hold and making > everyone happy. From a code reuse POV, it is an aberration to have an eclass that reinvents eclass include logic, having or having had flaws. Still from a code reuse POV, the package manager being able to export functions would reduce eclass boilterplate code, a package manager could look for EXPORT_FUNCTIONS and call default if absent. From a QA POV, eclass can work properly if called outside of src_* phases, ensuring PMS assumptions hold and making everyone happy. ...oh wait, we already have that! > And finally, ebuild code for the libc used by 99% of our users, > supporting cross-compilers, canadian crosses and what else wouldn't be > something I'd call a 'half-working hack'. Especially when it ends up with users reporting things like 'pkg_* phases are not being called'. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Mon, 20 Mar 2017 20:25:52 +0100 Ulrich Mueller wrote: > > On Mon, 20 Mar 2017, Alexis Ballier wrote: > > > What makes me wonder more are the proposed solutions: So far the > > only proposals I've seen are either inlining *all* the code or > > moving *all* the code into an eclass. Having a quick look at > > autoconf, it seems to me an intermediate solution would work > > perfectly fine for the above goals/rules: Put main.eblit into an > > eclass. The loading code then would access $FILESDIR only in src_* > > phases. This would likely work better for all parties and would > > allow to focus on better specifying this gray area of PMS instead. > > But is it desirable as a goal, that all packages in the tree use > regular eclasses, but two packages (autoconf and glibc) use something > else that is a "grey area"? No. Unless I've missed something, in which case please point it out, main.eblit is generic enough to be an eclass and if called only from src_* phases, it gets the whole thing out of this grey area.
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Mon, 20 Mar 2017 19:24:58 +0100 Michał Górny wrote: > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote: > > What makes me wonder more are the proposed solutions: So far the > > only proposals I've seen are either inlining *all* the code or > > moving *all* the code into an eclass. Having a quick look at > > autoconf, it seems to me an intermediate solution would work > > perfectly fine for the above goals/rules: Put main.eblit into an > > eclass. The loading code then would access $FILESDIR only in src_* > > phases. This would likely work better for all parties and would > > allow to focus on better specifying this gray area of PMS instead. > > Don't you find it a bad hypocritical that at the same time you oppose > committing an eclass for a single package and you support committing > an eclass to support half-working hack for a single package? > First, I don't oppose committing an eclass for a single package, I consider it out of scope of eclasses, that's all. But even if I had stronger positions, this one looks like a win-win situation to me: From a code reuse POV, it is an aberration to have packages reinvent eblit include logic, each of them having or having had its different flaws. Still from a code reuse POV, the eclass being able to export functions would reduce ebuild boilerplate code, an eblit eclass could test the presence of eblit code and call default if absent. From a QA POV, eblit functions can die horribly if called outside of src_* phases, ensuring PMS assumptions hold and making everyone happy. And finally, ebuild code for the libc used by 99% of our users, supporting cross-compilers, canadian crosses and what else wouldn't be something I'd call a 'half-working hack'. Alexis.
[gentoo-dev] [PATCH 2/2] sys-libs/ncurses: Remove parallel econf logic
Remove the parallel econf logic that adds a lot of complexity for minor
gain. It results in the output from different configure scripts being
mixed in the build log, making it unreadable. It causes econf to be run
in a subshell which is a PMS violation and can cause issues with some of
package manager implementations. Furthermore, the multijob parallel
processes are interleaved with multilib-build logic which is unsupported
and a very bad idea.
---
sys-libs/ncurses/ncurses-5.9-r101.ebuild | 11 ---
sys-libs/ncurses/ncurses-6.0-r1.ebuild | 9 +++--
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/sys-libs/ncurses/ncurses-5.9-r101.ebuild
b/sys-libs/ncurses/ncurses-5.9-r101.ebuild
index 76b8a76d3a72..c722d68f3208 100644
--- a/sys-libs/ncurses/ncurses-5.9-r101.ebuild
+++ b/sys-libs/ncurses/ncurses-5.9-r101.ebuild
@@ -1,11 +1,11 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# This version is just for the ABI .5 library
EAPI="5"
-inherit eutils toolchain-funcs multilib-minimal multiprocessing
+inherit eutils toolchain-funcs multilib-minimal
MY_PV=${PV:0:3}
MY_P=${PN}-${MY_PV}
@@ -55,8 +55,6 @@ src_configure() {
$(usex unicode 'ncursesw' '')
)
- multijob_init
-
# When installing ncurses, we have to use a compatible version of tic.
# This comes up when cross-compiling, doing multilib builds, upgrading,
# or installing for the first time. Build a local copy of tic whenever
@@ -69,16 +67,15 @@ src_configure() {
CXXFLAGS=${BUILD_CXXFLAGS} \
CPPFLAGS=${BUILD_CPPFLAGS} \
LDFLAGS="${BUILD_LDFLAGS} -static" \
- multijob_child_init do_configure cross --without-shared
--with-normal
+ do_configure cross --without-shared --with-normal
fi
multilib-minimal_src_configure
- multijob_finish
}
multilib_src_configure() {
local t
for t in "${NCURSES_TARGETS[@]}" ; do
- multijob_child_init do_configure "${t}"
+ do_configure "${t}"
done
}
diff --git a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
index 2ab63de41d4c..d98b23afb751 100644
--- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
+++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
@@ -3,7 +3,7 @@
EAPI="5"
-inherit eutils flag-o-matic toolchain-funcs multilib-minimal multiprocessing
+inherit eutils flag-o-matic toolchain-funcs multilib-minimal
MY_PV=${PV:0:3}
PV_SNAP=${PV:4}
@@ -61,8 +61,6 @@ src_configure() {
$(use unicode && usex threads 'ncursestw' '')
)
- multijob_init
-
# When installing ncurses, we have to use a compatible version of tic.
# This comes up when cross-compiling, doing multilib builds, upgrading,
# or installing for the first time. Build a local copy of tic whenever
@@ -87,16 +85,15 @@ src_configure() {
CXXFLAGS=${BUILD_CXXFLAGS} \
CPPFLAGS=${BUILD_CPPFLAGS} \
LDFLAGS="${BUILD_LDFLAGS} ${lbuildflags}" \
- multijob_child_init do_configure cross --without-shared
--with-normal
+ do_configure cross --without-shared --with-normal
fi
multilib-minimal_src_configure
- multijob_finish
}
multilib_src_configure() {
local t
for t in "${NCURSES_TARGETS[@]}" ; do
- multijob_child_init do_configure "${t}"
+ do_configure "${t}"
done
}
--
2.12.0
[gentoo-dev] [PATCH 1/2] dev-lang/jimtcl: Remove parallel econf code
The parallel econf code is used only with USE=static-libs, and even in
that case provides negligible speed gain. At the same time, it adds
a lot of complexity, causes the build logs to be unreadable mix of
output from both configure scripts and violates PMS by calling econf
in parallel which can cause issues with different package managers.
---
dev-lang/jimtcl/jimtcl-0.75-r1.ebuild | 10 --
dev-lang/jimtcl/jimtcl-0.76.ebuild| 10 --
dev-lang/jimtcl/jimtcl-.ebuild| 10 --
3 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/dev-lang/jimtcl/jimtcl-0.75-r1.ebuild
b/dev-lang/jimtcl/jimtcl-0.75-r1.ebuild
index d05b5040644f..180745bbe7da 100644
--- a/dev-lang/jimtcl/jimtcl-0.75-r1.ebuild
+++ b/dev-lang/jimtcl/jimtcl-0.75-r1.ebuild
@@ -1,9 +1,9 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
EAPI="5"
-inherit multiprocessing eutils
+inherit eutils
if [[ ${PV} == "" ]] ; then
EGIT_REPO_URI="http://repo.or.cz/r/jimtcl.git";
@@ -40,15 +40,13 @@ src_prepare() {
}
src_configure() {
- multijob_init
- CCACHE=None multijob_child_init econf --with-jim-shared
+ CCACHE=None econf --with-jim-shared
if use static-libs ; then
# The build does not support doing both simultaneously.
mkdir static-libs
cd static-libs
- CCACHE=None ECONF_SOURCE=${S} multijob_child_init econf
+ CCACHE=None ECONF_SOURCE=${S} econf
fi
- multijob_finish
}
src_compile() {
diff --git a/dev-lang/jimtcl/jimtcl-0.76.ebuild
b/dev-lang/jimtcl/jimtcl-0.76.ebuild
index a82e24c9b204..ecdcdc96fac5 100644
--- a/dev-lang/jimtcl/jimtcl-0.76.ebuild
+++ b/dev-lang/jimtcl/jimtcl-0.76.ebuild
@@ -1,9 +1,9 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
EAPI="5"
-inherit multiprocessing eutils
+inherit eutils
if [[ ${PV} == "" ]] ; then
EGIT_REPO_URI="http://repo.or.cz/r/jimtcl.git";
@@ -40,15 +40,13 @@ src_prepare() {
}
src_configure() {
- multijob_init
- CCACHE=None multijob_child_init econf --with-jim-shared
+ CCACHE=None econf --with-jim-shared
if use static-libs ; then
# The build does not support doing both simultaneously.
mkdir static-libs
cd static-libs
- CCACHE=None ECONF_SOURCE=${S} multijob_child_init econf
+ CCACHE=None ECONF_SOURCE=${S} econf
fi
- multijob_finish
}
src_compile() {
diff --git a/dev-lang/jimtcl/jimtcl-.ebuild
b/dev-lang/jimtcl/jimtcl-.ebuild
index d05b5040644f..180745bbe7da 100644
--- a/dev-lang/jimtcl/jimtcl-.ebuild
+++ b/dev-lang/jimtcl/jimtcl-.ebuild
@@ -1,9 +1,9 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
EAPI="5"
-inherit multiprocessing eutils
+inherit eutils
if [[ ${PV} == "" ]] ; then
EGIT_REPO_URI="http://repo.or.cz/r/jimtcl.git";
@@ -40,15 +40,13 @@ src_prepare() {
}
src_configure() {
- multijob_init
- CCACHE=None multijob_child_init econf --with-jim-shared
+ CCACHE=None econf --with-jim-shared
if use static-libs ; then
# The build does not support doing both simultaneously.
mkdir static-libs
cd static-libs
- CCACHE=None ECONF_SOURCE=${S} multijob_child_init econf
+ CCACHE=None ECONF_SOURCE=${S} econf
fi
- multijob_finish
}
src_compile() {
--
2.12.0
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
> On Mon, 20 Mar 2017, Alexis Ballier wrote: > What makes me wonder more are the proposed solutions: So far the > only proposals I've seen are either inlining *all* the code or > moving *all* the code into an eclass. Having a quick look at > autoconf, it seems to me an intermediate solution would work > perfectly fine for the above goals/rules: Put main.eblit into an > eclass. The loading code then would access $FILESDIR only in src_* > phases. This would likely work better for all parties and would > allow to focus on better specifying this gray area of PMS instead. But is it desirable as a goal, that all packages in the tree use regular eclasses, but two packages (autoconf and glibc) use something else that is a "grey area"? Also, can somebody please point me to the discussion that preceded the introduction of eblits. AFAICS they appeared sometime in 2007, but I cannot find anything in our mailing list archives. Ulrich pgp694x4vI54w.pgp Description: PGP signature
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Mon, Mar 20, 2017 at 2:15 PM, Alexis Ballier wrote:
> On Mon, 20 Mar 2017 13:40:51 -0400
> Mike Gilbert wrote:
>
>> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier
>> wrote:
>> > I just tried and with portage 2.3.5, FILESDIR is unset/empty in
>> > global scope here. At least an 'ewarn "${FILESDIR} blah"' outputs
>> > only ' blah'.
>>
>> I cannot reproduce this behavior.
>
> you made me wonder if i didn't make a typo in the variable name :)
>
> it seems not:
>
> $ git diff
> diff --git a/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild
> b/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild index
> f1a03d4280..104de94104 100644 ---
> a/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild +++
> b/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild @@ -41,6 +41,7
> @@ PATCHES=( "${FILESDIR}/${PN}-1.0.28-libav10.patch"
> )
>
> +ewarn "${FILESDIR} blah"
> src_prepare() {
> default
>
>
>
> $ emerge -pv alsa-plugins
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies | * blah
> -... done!
>
>
> Exiting on signal 2
>
>
> $ emerge --version
> Portage 2.3.5 (python 2.7.13-final-0, default/linux/amd64/13.0/desktop,
> gcc-6.3.0, glibc-2.24-r1, 4.10.1 x86_64)
>
Portage behavior is different during dependency calculation versus
actually executing the ebuild.
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote: > What makes me wonder more are the proposed solutions: So far the only > proposals I've seen are either inlining *all* the code or moving *all* > the code into an eclass. Having a quick look at autoconf, it seems to me > an intermediate solution would work perfectly fine for the above > goals/rules: Put main.eblit into an eclass. The loading code then would > access $FILESDIR only in src_* phases. This would likely work better > for all parties and would allow to focus on better specifying this gray > area of PMS instead. Don't you find it a bad hypocritical that at the same time you oppose committing an eclass for a single package and you support committing an eclass to support half-working hack for a single package? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Mon, 20 Mar 2017 13:40:51 -0400
Mike Gilbert wrote:
> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier
> wrote:
> > I just tried and with portage 2.3.5, FILESDIR is unset/empty in
> > global scope here. At least an 'ewarn "${FILESDIR} blah"' outputs
> > only ' blah'.
>
> I cannot reproduce this behavior.
you made me wonder if i didn't make a typo in the variable name :)
it seems not:
$ git diff
diff --git a/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild
b/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild index
f1a03d4280..104de94104 100644 ---
a/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild +++
b/media-plugins/alsa-plugins/alsa-plugins-1.1.1.ebuild @@ -41,6 +41,7
@@ PATCHES=( "${FILESDIR}/${PN}-1.0.28-libav10.patch"
)
+ewarn "${FILESDIR} blah"
src_prepare() {
default
$ emerge -pv alsa-plugins
These are the packages that would be merged, in order:
Calculating dependencies | * blah
-... done!
Exiting on signal 2
$ emerge --version
Portage 2.3.5 (python 2.7.13-final-0, default/linux/amd64/13.0/desktop,
gcc-6.3.0, glibc-2.24-r1, 4.10.1 x86_64)
Re: [gentoo-dev] Review: aspell-dict-r1.eclass
On Mon, Mar 20, 2017 at 10:27 AM, William Hubbs wrote: > Hi David, > > I'm curious, why the revbump? > > If all other eapis are staying in the eclass and the support is > identical, you don't need to create a new eclass, and there is a lot > less work involved in updating the ebuilds that inherit it. :-) He's making the eclass die for any EAPI other than 6. This breaks backward compatibility.
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier wrote:
> I just tried and with portage 2.3.5, FILESDIR is unset/empty in global
> scope here. At least an 'ewarn "${FILESDIR} blah"' outputs only ' blah'.
I cannot reproduce this behavior.
% emerge --version
Portage 2.3.5_p2 (python 3.5.3-final-0,
default/linux/amd64/13.0/desktop/plasma/systemd, gcc-5.4.0,
glibc-2.24-r1, 4.9.14 x86_64)
% cat foo-0.ebuild
EAPI=6
SLOT=0
KEYWORDS="amd64"
einfo "global: FILESDIR=${FILESDIR}"
pkg_setup() {
einfo "setup: FILESDIR=${FILESDIR}"
}
src_unpack() {
einfo "unpack: FILESDIR=${FILESDIR}"
}
% sudo emerge -1BO -j1 app-misc/foo
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) app-misc/foo-0::local
* global: FILESDIR=/home/floppym/repos/local/app-misc/foo/files
* setup: FILESDIR=/home/floppym/repos/local/app-misc/foo/files
>>> Unpacking source...
* unpack: FILESDIR=/home/floppym/repos/local/app-misc/foo/files
>>> Source unpacked in /x/portage/app-misc/foo-0/work
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Mon, 20 Mar 2017 15:12:43 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Alexis Ballier wrote:
>
> >> After the PMS change, we will have the same properties for DISTDIR,
> >> FILESDIR, WORKDIR, and S. Namely:
> >>
> >> - All four variables will be valid in src_* phases and in global
> >> scope
> >> - They will have a consistent value in the ebuild environment
> >> - The actual directories must not be accessed in global scope
>
> > Please correct me if I'm wrong, but then portage's behavior of
> > sending empty FILESDIR when it should not be used is wrong after
> > that, right ?
>
> No. "Consistent" only means that it has a constant value when it is
> defined, namely in src_* functions and in global scope.
I just tried and with portage 2.3.5, FILESDIR is unset/empty in global
scope here. At least an 'ewarn "${FILESDIR} blah"' outputs only ' blah'.
This case is already accounted for in autoconf, but you seem to want to
change it to having it set to a temptative value that may not exist
for pkg_* phases. Plus aiming at sourcing ebuilds only once (so that
if the eblit sourcing fails once you don't get a second chance). This
is also a desirable goal; I'm not sure if FILESDIR access rules are
sufficient for this to happen but they're definitely necessary.
What makes me wonder more are the proposed solutions: So far the only
proposals I've seen are either inlining *all* the code or moving *all*
the code into an eclass. Having a quick look at autoconf, it seems to me
an intermediate solution would work perfectly fine for the above
goals/rules: Put main.eblit into an eclass. The loading code then would
access $FILESDIR only in src_* phases. This would likely work better
for all parties and would allow to focus on better specifying this gray
area of PMS instead.
> > The idea behind FILESDIR being valid only in src_* phases is to
> > allow portage-tree-less binpkgs to work. Not sure if that's even
> > possible right now, but that is definitely a desirable goal.
>
> > If I understand correctly, the change you mention would mean
> > FILESDIR will be "constant". Which is good since that'd avoid
> > regenerating the environment. However, this breaks autoconf ebuild
> > relying on FILESDIR being empty when invalid and this would trigger
> > the 'source $FILESDIR/... || die' part making the ebuild die in
> > global scope.
>
> Obviously the FILESDIR variable cannot be empty in global scope if
> PATCHES=("${FILESDIR}"/foo.patch) is supposed to work in EAPI 6.
I'm afraid it sometimes is with current portage versions.
[...]
Alexis.
Re: [gentoo-dev] Review: aspell-dict-r1.eclass
Hi David, I'm curious, why the revbump? If all other eapis are staying in the eclass and the support is identical, you don't need to create a new eclass, and there is a lot less work involved in updating the ebuilds that inherit it. :-) Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
> On Mon, 20 Mar 2017, Alexis Ballier wrote:
>> After the PMS change, we will have the same properties for DISTDIR,
>> FILESDIR, WORKDIR, and S. Namely:
>>
>> - All four variables will be valid in src_* phases and in global scope
>> - They will have a consistent value in the ebuild environment
>> - The actual directories must not be accessed in global scope
> Please correct me if I'm wrong, but then portage's behavior of
> sending empty FILESDIR when it should not be used is wrong after
> that, right ?
No. "Consistent" only means that it has a constant value when it is
defined, namely in src_* functions and in global scope.
> The idea behind FILESDIR being valid only in src_* phases is to
> allow portage-tree-less binpkgs to work. Not sure if that's even
> possible right now, but that is definitely a desirable goal.
> If I understand correctly, the change you mention would mean
> FILESDIR will be "constant". Which is good since that'd avoid
> regenerating the environment. However, this breaks autoconf ebuild
> relying on FILESDIR being empty when invalid and this would trigger
> the 'source $FILESDIR/... || die' part making the ebuild die in
> global scope.
Obviously the FILESDIR variable cannot be empty in global scope if
PATCHES=("${FILESDIR}"/foo.patch) is supposed to work in EAPI 6.
> There are probably simpler fixes than the proposed patches, but this
> does indeed raise the question whether this is a backwards breaking
> change or not.
The spec will change from "not consistent" to "consistent" across
phases. Where "not consistent" meant that ebuilds could not rely on
the variable having the same value. I did *not* imply that ebuilds
could rely on the variable having a different value in each phase.
Ulrich
pgp8CF_rBRxcS.pgp
Description: PGP signature
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Mon, 20 Mar 2017 10:49:40 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Mike Frysinger wrote:
>
> > obvious NAK until you sort out the open questions already raised
> > about the backwards breaking change you're trying to land in PMS.
>
> There are indeed some PMS patches pending about DISTDIR, FILESDIR,
> WORKDIR, and S, but I fail to see where they would break backwards
> compatibility.
>
> If you look at the last council approved PMS version [1], you'll find
> that DISTDIR and FILESDIR are only valid in src_* phases and are not
> guaranteed to have a consistent value across phases. The problem with
> this is that it would not allow assignment of the PATCHES array in
> global scope, e.g.:
>
> PATCHES=( "${DISTDIR}"/foo.patch "${WORKDIR}"/bar.patch )
>
> After the PMS change, we will have the same properties for DISTDIR,
> FILESDIR, WORKDIR, and S. Namely:
>
> - All four variables will be valid in src_* phases and in global scope
> - They will have a consistent value in the ebuild environment
> - The actual directories must not be accessed in global scope
>
> One could argue that this was overseen when EAPI 6 was approved.
> In any case, ebuilds will be able to rely on more things than before.
Please correct me if I'm wrong, but then portage's behavior of sending
empty FILESDIR when it should not be used is wrong after that, right ?
The idea behind FILESDIR being valid only in src_* phases is to allow
portage-tree-less binpkgs to work. Not sure if that's even possible
right now, but that is definitely a desirable goal.
If I understand correctly, the change you mention would mean FILESDIR
will be "constant". Which is good since that'd avoid regenerating the
environment. However, this breaks autoconf ebuild relying on FILESDIR
being empty when invalid and this would trigger the 'source
$FILESDIR/... || die' part making the ebuild die in global scope.
There are probably simpler fixes than the proposed patches, but this
does indeed raise the question whether this is a backwards breaking
change or not.
Alexis.
[gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
> On Mon, 20 Mar 2017, Mike Frysinger wrote:
> obvious NAK until you sort out the open questions already raised
> about the backwards breaking change you're trying to land in PMS.
There are indeed some PMS patches pending about DISTDIR, FILESDIR,
WORKDIR, and S, but I fail to see where they would break backwards
compatibility.
If you look at the last council approved PMS version [1], you'll find
that DISTDIR and FILESDIR are only valid in src_* phases and are not
guaranteed to have a consistent value across phases. The problem with
this is that it would not allow assignment of the PATCHES array in
global scope, e.g.:
PATCHES=( "${DISTDIR}"/foo.patch "${WORKDIR}"/bar.patch )
After the PMS change, we will have the same properties for DISTDIR,
FILESDIR, WORKDIR, and S. Namely:
- All four variables will be valid in src_* phases and in global scope
- They will have a consistent value in the ebuild environment
- The actual directories must not be accessed in global scope
One could argue that this was overseen when EAPI 6 was approved.
In any case, ebuilds will be able to rely on more things than before.
Ulrich
[1] https://projects.gentoo.org/pms/6/pms.html#x1-118002
pgpTuacvZ_DpV.pgp
Description: PGP signature
[gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On 16 Mar 2017 10:38, Michał Górny wrote: > Convert the usage of eblits in sys-devel/autoconf into an equivalent > eclass. This makes the ebuilds more readable, more predictable and fixes > compliance with stricter versions of the package manager (i.e. a future > release of Portage). obvious NAK until you sort out the open questions already raised about the backwards breaking change you're trying to land in PMS. the point of having EAPI's in the first place is that we don't break them, but change the behavior across new versions. your patches aren't fixing actual bugs, just things you "don't like". -mike signature.asc Description: Digital signature
