Re: [gentoo-portage-dev] bin/isolated-functions.sh USERLAND setting
On 28-07-2022 20:11:24 +0200, Fabian Groffen wrote: > On 28-07-2022 19:57:50 +0200, Arfrever Frehtes Taifersar Arahesis wrote: > > But this code starts with 'if [[ -z ${USERLAND} ]]', so it should not > > be run when USERLAND="GNU". > > > > USERLAND="GNU" is set in make.defaults, which is parsed by Portage > > early (at Python side) and these values are passed by Portage to > > ebuild.sh subprocess. > > Hmmm, that would be nice, features/prefix/make.defaults includes setting > that. > > Makes me still wonder why we do this, is it a fallback for when the > profiles aren't available (no tree yet) or something? > > It exports XARGS, which only used in the ___parallel_xargs function. > That function in turn is used in 2 places. So all this stuff is done to > add -r to xargs if xargs isn't BSD xargs. Iow --no-run-if-empty, which > is cool, but apparently not strictly necessary (fugly warning I guess at > worst). We're already checking xargs to support --max-procs=, so we > could in the same go check for support of --no-run-if-empty, and drop > the whole XARGS thing and declutter the code quite a lot :) Sorry, I grepped wrong. XARGS is used throughout the code, so it needs to be initialised in isolated-functions.sh. It could be initialised by simply probing instead of relying on uname though. As for USERLAND, emerge-webrsync and delta-webrsync appear to use it, but they retrieve it from portageq, so I guess USERLAND is not really used in Portage itself. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-portage-dev] bin/isolated-functions.sh USERLAND setting
On 28-07-2022 19:57:50 +0200, Arfrever Frehtes Taifersar Arahesis wrote: > 2022-07-28 17:47 UTCに、Fabian Groffen は書いた: > > bin/isolated-functions.sh does the following bit: > > > > if [[ -z ${USERLAND} ]] ; then > >case $(uname -s) in > >*BSD|DragonFly) > >export USERLAND="BSD" > >;; > >*) > >export USERLAND="GNU" > >;; > >esac > > fi > > > > (after which it uses USERLAND for a single purpose, to export XARGS to > > either GNU '[g]xargs -r', or BSD 'xargs') > > > > This bit is problematic for Prefix, because Prefix may run on *BSD, but > > use USERLAND=GNU. > > But this code starts with 'if [[ -z ${USERLAND} ]]', so it should not > be run when USERLAND="GNU". > > USERLAND="GNU" is set in make.defaults, which is parsed by Portage > early (at Python side) and these values are passed by Portage to > ebuild.sh subprocess. Hmmm, that would be nice, features/prefix/make.defaults includes setting that. Makes me still wonder why we do this, is it a fallback for when the profiles aren't available (no tree yet) or something? It exports XARGS, which only used in the ___parallel_xargs function. That function in turn is used in 2 places. So all this stuff is done to add -r to xargs if xargs isn't BSD xargs. Iow --no-run-if-empty, which is cool, but apparently not strictly necessary (fugly warning I guess at worst). We're already checking xargs to support --max-procs=, so we could in the same go check for support of --no-run-if-empty, and drop the whole XARGS thing and declutter the code quite a lot :) Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-portage-dev] bin/isolated-functions.sh USERLAND setting
2022-07-28 17:47 UTCに、Fabian Groffen は書いた: > bin/isolated-functions.sh does the following bit: > > if [[ -z ${USERLAND} ]] ; then >case $(uname -s) in >*BSD|DragonFly) >export USERLAND="BSD" >;; >*) >export USERLAND="GNU" >;; >esac > fi > > (after which it uses USERLAND for a single purpose, to export XARGS to > either GNU '[g]xargs -r', or BSD 'xargs') > > This bit is problematic for Prefix, because Prefix may run on *BSD, but > use USERLAND=GNU. But this code starts with 'if [[ -z ${USERLAND} ]]', so it should not be run when USERLAND="GNU". USERLAND="GNU" is set in make.defaults, which is parsed by Portage early (at Python side) and these values are passed by Portage to ebuild.sh subprocess.
[gentoo-portage-dev] bin/isolated-functions.sh USERLAND setting
Hi, bin/isolated-functions.sh does the following bit: if [[ -z ${USERLAND} ]] ; then case $(uname -s) in *BSD|DragonFly) export USERLAND="BSD" ;; *) export USERLAND="GNU" ;; esac fi (after which it uses USERLAND for a single purpose, to export XARGS to either GNU '[g]xargs -r', or BSD 'xargs') This bit is problematic for Prefix, because Prefix may run on *BSD, but use USERLAND=GNU. The problem is theoretical at this point, occasionally people come in and want to use Prefix on *BSD again. Now I think Gentoo/BSD is theoretical too. It officially is no longer maintained[1]. So, question here is, do we want to retain this bit of historical compatibility work (also check things like gsed wrapper), or can it go, basically removing a potential problem for Gentoo Prefix? [1] https://wiki.gentoo.org/wiki/Gentoo_FreeBSD -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] emake: explicitly set SHELL
2022-07-26 07:03 UTCに、Florian Schmaus は書いた: > But then I wondered if "make SHELL=$BROOT/bin/sh" wouldn't override > explicitly set SHELL values in Makefiles. Assume a package has > > SHELL = /bin/zsh > > in one of its Makefiles. Then emake would reset this to 'sh'. Which > appears like it could cause build issues. > > If this is the case, then I am not sure what we can do about it. It > appears fragile, if not impossible, to ask 'make' which value for SHELL > it would assume, so that emake could adjust the path. Another option > could be that affected packages define a variable in their ebuild, e.g. > EMAKE_SHELL="zsh", which emake could extend with BROOT before passing > the resulting value as SHELL to make. If there was such package, it could just override SHELL on emake invocation: src_compile() { emake SHELL="${BROOT}/bin/zsh" # Or: emake SHELL="$(type -P zsh)" }