[gentoo-dev] [PATCH] eclass/cargo.eclass: add cargo_src_configure (revised)
simple src_configure implementation inspired by cmake.eclass
Closes: https://bugs.gentoo.org/721936
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 77 -
1 file changed, 70 insertions(+), 7 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ccbf87aa9a6..77c8e90755b 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -22,7 +22,7 @@ esac
inherit multiprocessing toolchain-funcs
-EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
+EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
IUSE="${IUSE} debug"
@@ -34,6 +34,29 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
# Allows overriding the default cwd to run cargo install from
: ${CARGO_INSTALL_PATH:=.}
+# @VARIABLE: myfeatures
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Optional cargo features defined as bash array. Should be defined before
calling
+# src_configure.
+# If this array is not empty, --no-default-features is passed to cargo.
+# To enable default crate features in that case you can add 'default' to the
array.
+# Extra positional arguments supplied to this function
+# will be passed to cargo in all phases.
+# Make sure all cargo subcommands support flags passed here.
+#
+# Example for package that has x11 and wayland as features, and enables
default set.
+# @CODE
+# src_configure() {
+# local myfeatures=(
+# default
+# $(usex X x11 '')
+# $(usev wayland)
+# )
+# cargo_src_configure
+# }
+# @CODE
+
# @FUNCTION: cargo_crate_uris
# @DESCRIPTION:
# Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -112,6 +135,7 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
pushd "${S}" > /dev/null || die
+ # need to specify CARGO_HOME before cargo_gen_config fired
CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
@@ -151,6 +175,47 @@ cargo_gen_config() {
EOF
# honor NOCOLOR setting
[[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color =
'never'" >> "${ECARGO_HOME}/config"
+
+ export CARGO_HOME="${ECARGO_HOME}"
+}
+
+# @FUNCTION: cargo_src_configure
+# @DESCRIPTION:
+# Configure cargo package features and arguments.
+# Example for package that explicitly builds only 'foo' binary and
+# enables single feature 'barfeature', disabling default feature set.
+# will pass '--no-default-features --features barfeature --bin foo'
+# in src_{compile,test,install}
+# @CODE
+# src_configure() {
+# local myfeatures=(
+# barfeature
+# )
+# cargo_src_configure --bin foo
+# }
+# @CODE
+
+cargo_src_configure() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ [[ -z ${myfeatures} ]] && declare -a myfeatures=()
+ local myfeaturestype=$(declare -p myfeatures 2>&-)
+ if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
+ die "myfeatures must be declared as array"
+ fi
+
+ # transform array from simple feature list
+ # to multiple cargo args:
+ # --features feature1 --features feature2 ...
+ # this format is chosen because 2 other methods of
+ # listing features (space OR comma separated) require
+ # more fiddling with strings we'd like to avoid here.
+ myfeatures=( ${myfeatures[@]/#/--features } )
+
+ # prepend --no-default features if myfeatures array is not empty,
append extra args
+ readonly ECARGO_ARGS=( ${myfeatures:+--no-default-features
${myfeatures[@]}} ${@} )
+
+ [[ ${ECARGO_ARGS[@]} ]] && einfo "Configured with: ${ECARGO_ARGS[@]}"
}
# @FUNCTION: cargo_src_compile
@@ -159,11 +224,9 @@ cargo_gen_config() {
cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
- export CARGO_HOME="${ECARGO_HOME}"
-
tc-export AR CC
- cargo build $(usex debug "" --release) "$@" \
+ cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@" \
|| die "cargo build failed"
}
@@ -173,8 +236,8 @@ cargo_src_compile() {
cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
- cargo install --path ${CARGO_INSTALL_PATH} \
- --root="${ED}/usr" $(usex debug --debug "") "$@" \
+ cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
+ $(usex debug --debug "") ${ECARGO_ARGS[@]} "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
rm -f "${ED}/usr/.crates2.json"
@@ -188,7 +251,7 @@ cargo_src_install() {
cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
- cargo test $(usex debug "" --release) "$@" \
+ cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@" \
|| die "cargo test failed"
}
--
2.27.0
[gentoo-dev] Re: [PATCH v2] meson.eclass: override 'nm' tool with tuple-prefixed one
On Fri, 12 Jun 2020 17:43:10 -0400
Mike Gilbert wrote:
> On Fri, Jun 12, 2020 at 5:25 PM Sergei Trofimovich wrote:
> >
> > x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
> > tool on sys-devel/binutils-config[-native-symlinks] system as:
> > `meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
> >
> > It's caused by the code that locates the tool as:
> > `prog_nm = find_program('nm')`.
> >
> > The change adds 'nm' tool along with other binutils tools.
> >
> > CC: William Hubbs
> > CC: Mike Gilbert
> > Closes: https://bugs.gentoo.org/720886
> > Signed-off-by: Sergei Trofimovich
> > ---
> > eclass/meson.eclass | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > index e79faa1beea..1590c1f14cf 100644
> > --- a/eclass/meson.eclass
> > +++ b/eclass/meson.eclass
> > @@ -178,6 +178,7 @@ _meson_create_cross_file() {
> > cpp = $(_meson_env_array "$(tc-getCXX)")
> > fortran = $(_meson_env_array "$(tc-getFC)")
> > llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
> > + nm = $(_meson_env_array "$(tc-getNM)")
> > objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
> > objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
> > pkgconfig = '$(tc-getPKG_CONFIG)'
> > @@ -228,6 +229,7 @@ _meson_create_native_file() {
> > cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
> > fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
> > llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
> > + nm = $(_meson_env_array "$(tc-getBUILD_NM)")
> > objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
> > objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
> > pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
> > --
> > 2.27.0
> >
>
> Looks good.
Thank you! Pushed as:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=da03d40f146a646c38e75fd0a6fc299b5aeba505
--
Sergei
[gentoo-dev] Re: [PATCH v2] meson.eclass: override 'nm' tool with tuple-prefixed one
On Fri, Jun 12, 2020 at 5:25 PM Sergei Trofimovich wrote:
>
> x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
> tool on sys-devel/binutils-config[-native-symlinks] system as:
> `meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
>
> It's caused by the code that locates the tool as:
> `prog_nm = find_program('nm')`.
>
> The change adds 'nm' tool along with other binutils tools.
>
> CC: William Hubbs
> CC: Mike Gilbert
> Closes: https://bugs.gentoo.org/720886
> Signed-off-by: Sergei Trofimovich
> ---
> eclass/meson.eclass | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index e79faa1beea..1590c1f14cf 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -178,6 +178,7 @@ _meson_create_cross_file() {
> cpp = $(_meson_env_array "$(tc-getCXX)")
> fortran = $(_meson_env_array "$(tc-getFC)")
> llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
> + nm = $(_meson_env_array "$(tc-getNM)")
> objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
> objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
> pkgconfig = '$(tc-getPKG_CONFIG)'
> @@ -228,6 +229,7 @@ _meson_create_native_file() {
> cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
> fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
> llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
> + nm = $(_meson_env_array "$(tc-getBUILD_NM)")
> objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
> objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
> pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
> --
> 2.27.0
>
Looks good.
[gentoo-dev] [PATCH v2] meson.eclass: override 'nm' tool with tuple-prefixed one
x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
tool on sys-devel/binutils-config[-native-symlinks] system as:
`meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
It's caused by the code that locates the tool as:
`prog_nm = find_program('nm')`.
The change adds 'nm' tool along with other binutils tools.
CC: William Hubbs
CC: Mike Gilbert
Closes: https://bugs.gentoo.org/720886
Signed-off-by: Sergei Trofimovich
---
eclass/meson.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index e79faa1beea..1590c1f14cf 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -178,6 +178,7 @@ _meson_create_cross_file() {
cpp = $(_meson_env_array "$(tc-getCXX)")
fortran = $(_meson_env_array "$(tc-getFC)")
llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
+ nm = $(_meson_env_array "$(tc-getNM)")
objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
pkgconfig = '$(tc-getPKG_CONFIG)'
@@ -228,6 +229,7 @@ _meson_create_native_file() {
cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
+ nm = $(_meson_env_array "$(tc-getBUILD_NM)")
objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
--
2.27.0
Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
All, this patch is being committed today. Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug
On 6/12/20 10:54 AM, Jaco Kroon wrote: > Hi Aisha, > > On 2020/06/12 13:44, Aisha Tammy wrote: >> On 6/12/20 6:55 AM, Jaco Kroon wrote: >>> Hi, >>> >>> Can we possibly include the concept of "helping to file bug reports" here? >>> >>> For example, I've got an issue (which hasn't annoyed me just quite >>> enough yet to put effort in) where on bootup after xdm init script >>> starts it takes ~2 minutes before slim login is displayed. But I don't >>> know enough of the workings of that to even understand if this is an >>> Xorg or slim (or dbus) bug ... >>> >> BugDay is not for creating bugs, its for squashing them. >> >> You can create the bugs today and then if it is in one of the top voted >> categories (old bugs, in this case) you might be able to convince interested >> devs to target your specific ones. > > Fair enough. > > In this case I've no idea where to start with filing a sensible bug > though :). So what it really boils down to is that I think we need to > provide a way to help users help us by providing the ability to interact > with people (Yea, #gentoo works up to a point) that can assist with > basic trouble-shooting to point people towards that which could be the > problem to help with filing better bug reports. > > I've been hunting a graphics terminal corruption issue with urxvt now, > and in the man page you get this: > > [Please note that many X servers (and libXft) are buggy with > respect to "-depth 32" > and/or alpha channels, and will cause all sorts of graphical > corruption. This is > harmless, but we can't do anything about this, so watch out] > > So where to from here? Researching that it seems most other similar > reports relate to 4th-gen intel graphics ... heck, this was even > attributed to pango at some point, and some other dock launcher which > name I can't remember now. I've now explicitly set depth to 24 so I'll > know soon enough if this is the issue. To confuse the matter even more, > I've had the same corruption using aterm, and in xterm as well. But it > *only* seems to happen with terminal emulators. > > Then there is the issue I described above. > > Currently I have another two or three *desktop* related issues that > plague me, none of which are easy to point where the bug may actually > be, so to file a bug given this is hard. > > Anyway, count me in on bugday if I can be there at all. This should be > interesting. Without knowing any specifics this looks like it might be either related to font aliasing/ encoding. If there are open bugs for all of them, they would be a good candidate for investigating the X font rendering library (libXft). For people who don't know how to file bugs: You can go on bugs.gentoo.org and look around if these are already filed else open new bugs. > > Looking at the previous bug day there is one thing I don't see: > > How does this approach work? In oher words, the lead-up and > organization seems to be fairly well spelt out - but how does it work on > the day? When does it actually start? Or is this a world-wide rolling > time GMT+12 starts waking up until GMT-12 starts heading to bed? This > is the opportunity to market the event. > Good point! Information dump time - The next bugday is on 4th July (and every first saturday of the month, from then on) It is a world wide event, with a lot of flexibility on timing. Its not constrained to just GMT or a particular time zone. The event will mostly be dependent on when devs and other people start rolling in and ramping up. We will continue going until people get tired and/or a sensible amount of time to be called a "day" has passed, Most of the interaction will be happening on #gentoo-bugday, with devs talking about bugs that they are working on. Users are welcome to come and interact but don't expect us to be trouble shooting for you. Any specific interesting bugs that you can report, the more wide ranging effects of that bug, the more likely it is that somebody will pick it up. How you can help: there are a lot of open bugs on bugzilla but it is hard to pinpoint what the exact reasons for every bug are. It is possible that some bugs get ignore for a long time and become legacy. You can help is find a lot of related bugs that you think can be solved at the same time, because they seem to be sharing the same problem. These kinds of bugs will be very useful to know. Or you can just show up to motivate us and cheer us on, that helps too :) Aisha > Kind Regards, > Jaco > >> >> Aisha >> >>> Guessing #gentoo may also be of help in regards to the above, so this is >>> really just a suggestion. Yes, it will generate more bugs, but >>> hopefully the concept will allow for creating targeted bugs rather than >>> overly generic difficult to trouble-shoot bugs. >>> >>> Kind Regards, >>> Jaco >>> >>> On 2020/06/11 14:41, Aisha Tammy wrote: >>> # Gentoo BugDay Come join us over at #gentoo-bugday on freen
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 6/12/20 11:59 AM, Luca Barbato wrote: > On 12/06/2020 18:24, Georgy Yakovlev wrote: >> On 6/12/20 4:16 AM, Luca Barbato wrote: >>> On 12/06/2020 11:04, Georgy Yakovlev wrote: +# cargo_src_configure --no-default-features >>> >>> Shall we default in not-defaulting so we can spare some boilerplate? >> I don't think so. Let me explain. >> >> First of all, this will force to explicitly micro-manage all the >> features for all the packages in the tree. >> > > The idea is: > - if myfeatures is empty, do not pass --no-default-features. > - if myfeatures has content, automatically pass --no-default-features. > I realized that was the intention after sending the email. That makes more sense, I'll scout toml files a bit and probably will implement it. I certainly remember scenarios where turning off default features is highly undesirable, but toggling extras makes sense. > --no-default-features --features default seems working as intended btw. > in that case local myfeatures=( default $(usex flagX featureX '') ) -> --no-default-features --features default --features featureX looks quite good actually. just need to make sure we pass --no-default-features first in order in that scenario. > lu
[gentoo-dev] Re: [PATCH] meson.eclass: override 'nm' tool with tuple-prefixed one
On Fri, Jun 12, 2020 at 2:37 PM Sergei Trofimovich wrote:
>
> x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
> tool on sys-devel/binutils-config[-native-symlinks] system as:
> `meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
>
> It's caused by the code that locates the tool as:
> `prog_nm = find_program('nm')`.
>
> The change adds 'nm' tool along with other binutils tools.
>
> CC: William Hubbs
> CC: Mike Gilbert
> Closes: https://bugs.gentoo.org/720886
> Signed-off-by: Sergei Trofimovich
> ---
> eclass/meson.eclass | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index e79faa1beea..20f74a29b83 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -178,6 +178,7 @@ _meson_create_cross_file() {
> cpp = $(_meson_env_array "$(tc-getCXX)")
> fortran = $(_meson_env_array "$(tc-getFC)")
> llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
> + nm = $(_meson_env_array "$(tc-getNM nm)")
> objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
> objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
> pkgconfig = '$(tc-getPKG_CONFIG)'
> @@ -228,6 +229,7 @@ _meson_create_native_file() {
> cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
> fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
> llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
> + nm = $(_meson_env_array "$(tc-getBUILD_NM nm)")
> objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
> objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
> pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
You are passing an extraneous "nm" to tc-getNM and tc-getBUILD_NM.
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 12/06/2020 18:24, Georgy Yakovlev wrote: On 6/12/20 4:16 AM, Luca Barbato wrote: On 12/06/2020 11:04, Georgy Yakovlev wrote: +# cargo_src_configure --no-default-features Shall we default in not-defaulting so we can spare some boilerplate? I don't think so. Let me explain. First of all, this will force to explicitly micro-manage all the features for all the packages in the tree. The idea is: - if myfeatures is empty, do not pass --no-default-features. - if myfeatures has content, automatically pass --no-default-features. --no-default-features --features default seems working as intended btw. lu
[gentoo-dev] [PATCH] meson.eclass: override 'nm' tool with tuple-prefixed one
x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
tool on sys-devel/binutils-config[-native-symlinks] system as:
`meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
It's caused by the code that locates the tool as:
`prog_nm = find_program('nm')`.
The change adds 'nm' tool along with other binutils tools.
CC: William Hubbs
CC: Mike Gilbert
Closes: https://bugs.gentoo.org/720886
Signed-off-by: Sergei Trofimovich
---
eclass/meson.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index e79faa1beea..20f74a29b83 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -178,6 +178,7 @@ _meson_create_cross_file() {
cpp = $(_meson_env_array "$(tc-getCXX)")
fortran = $(_meson_env_array "$(tc-getFC)")
llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
+ nm = $(_meson_env_array "$(tc-getNM nm)")
objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
pkgconfig = '$(tc-getPKG_CONFIG)'
@@ -228,6 +229,7 @@ _meson_create_native_file() {
cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
+ nm = $(_meson_env_array "$(tc-getBUILD_NM nm)")
objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
--
2.27.0
[gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support
On 6/11/20 8:11 PM, Georgy Yakovlev wrote:
> no consumers left in the tree
>
> Signed-off-by: Georgy Yakovlev
> ---
> eclass/cargo.eclass | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..ccbf87aa9a6 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -16,7 +16,6 @@ _CARGO_ECLASS=1
> RUST_DEPEND=">=virtual/rust-1.37.0"
>
> case ${EAPI} in
> - 6) DEPEND="${RUST_DEPEND}";;
> 7) BDEPEND="${RUST_DEPEND}";;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
> esac
>
merged c30b9bed5d16025c59b878e9dff69b90af41bf4d
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 6/12/20 6:03 AM, Kent Fredric wrote:
I've replied privately by mistake, replying to the list again.
> On Fri, 12 Jun 2020 02:04:51 -0700
> Georgy Yakovlev wrote:
>
>> +# cargo_src_configure --no-default-features
>
> Looking at the source, I don't see how this is passed from this command to
> anything.
yeah I caught it later, will just pass it as
readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } ${@} )
>
>> +# transform array from simple feature list
>> +# to multiple cargo args:
>> +# --features feature1 --features feature2 ...
>> +readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
>
> Is this really necessary?
>
>> cargo --features "feature1 feature2"
>
> is perfectly legal.
>
cargo is very picky about how multiple features are quoted in your example.
like REALLY picky, and it breaks depending on how array is passed.
I had that initially but found that just not worth it because it may break.
multiple toggles is perfectly legal way to pass features as well and is
more robust in this situation IMO.
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 6/12/20 4:16 AM, Luca Barbato wrote: > On 12/06/2020 11:04, Georgy Yakovlev wrote: >> +# cargo_src_configure --no-default-features > > Shall we default in not-defaulting so we can spare some boilerplate? I don't think so. Let me explain. First of all, this will force to explicitly micro-manage all the features for all the packages in the tree. Like 90% of crates I've seen ship working choice and there's no benefit of micro-management, and no benefit of enabling non-default features at all. Not all features need to be exposed as use-flags, and this was quite consistent situation so far. I know it may sound a bit strange but automagic in this case works with no downsides, unlike other languages/frameworks/build-systems. Also it will break all the tree packages which do not manage features directly if merged as is. Not sure if --features=default will activate default set and how it will react to being passed along. --no-default-features --features default IDK, looks kinda unnatural. I have a feeling that we'll get more boilerplate if we pass --no-default-features than if we don't. We can re-evaluate as time goes by, but for now I see no major benefit and only downsides. > > lu >
Re: [gentoo-dev] [RFC] Codec project
On Fri, 12 Jun 2020 10:58:24 -0400 Rich Freeman wrote: > On Fri, Jun 12, 2020 at 10:33 AM Alexis Ballier > wrote: > > > > What about /j #gentoo-media, discuss, join the current projects, > > get a few things done (there is a lot of choice there ;) ), maybe > > orphan unmaintained players/viewers, or check if they are > > maintained and hand them to a specific maintainer, and then see > > about merging or splitting all those projects *after* gaining > > experience and knowledge about the peculiarities of some of those > > packages ? > > > > Probably best to leave the details up to those doing the work, but I > would suggest this as a guideline: > > Keep the scope reasonable. If you expand the scope to a point where > 90% of the project members don't care about 50% of the project scope, > then you're setting yourself up for a repeat of the past. You want > 80% of the project members to be interested in 80% of the packages > being maintained ideally. Sure, there will be little niches that a > subset are more interested in, but you want to keep it focused around > a core where coordination makes sense. You can have different roles > in the project but it should still be one project. Totally agree here. Back in the days we had split proaudio from sound for this very reason. > If most of the project members aren't talking to each other about most > of the things they're doing in the project, then it isn't really a > project - it is just a category tag. The point of a project is to > coordinate things that actually NEED to be coordinated or at least > benefit from it in some way. It is not like a KDE, gnome or gstreamer project that has very tight coordination needs, so we shouldn't judge those on the same grounds, but from time to time, when a core library changes its API it needs a project-wide coordination (plus a few extra revdep here and there that you get to know over time). That's more how I see coordination there. It is not as critical nor as frequent as it used to be but still happens from time to time. Having a codec project goes against that IMHO, we'd end up with a category tag where there's no relation between any of the package except they're media libraries. Alexis.
Re: [gentoo-dev] [RFC] Codec project
On Fri, Jun 12, 2020 at 10:33 AM Alexis Ballier wrote: > > What about /j #gentoo-media, discuss, join the current projects, get a > few things done (there is a lot of choice there ;) ), maybe orphan > unmaintained players/viewers, or check if they are maintained and hand > them to a specific maintainer, and then see about merging or splitting > all those projects *after* gaining experience and knowledge about the > peculiarities of some of those packages ? > Probably best to leave the details up to those doing the work, but I would suggest this as a guideline: Keep the scope reasonable. If you expand the scope to a point where 90% of the project members don't care about 50% of the project scope, then you're setting yourself up for a repeat of the past. You want 80% of the project members to be interested in 80% of the packages being maintained ideally. Sure, there will be little niches that a subset are more interested in, but you want to keep it focused around a core where coordination makes sense. You can have different roles in the project but it should still be one project. If most of the project members aren't talking to each other about most of the things they're doing in the project, then it isn't really a project - it is just a category tag. The point of a project is to coordinate things that actually NEED to be coordinated or at least benefit from it in some way. -- Rich
Re: [gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug
Hi Aisha, On 2020/06/12 13:44, Aisha Tammy wrote: > On 6/12/20 6:55 AM, Jaco Kroon wrote: >> Hi, >> >> Can we possibly include the concept of "helping to file bug reports" here? >> >> For example, I've got an issue (which hasn't annoyed me just quite >> enough yet to put effort in) where on bootup after xdm init script >> starts it takes ~2 minutes before slim login is displayed. But I don't >> know enough of the workings of that to even understand if this is an >> Xorg or slim (or dbus) bug ... >> > BugDay is not for creating bugs, its for squashing them. > > You can create the bugs today and then if it is in one of the top voted > categories (old bugs, in this case) you might be able to convince interested > devs to target your specific ones. Fair enough. In this case I've no idea where to start with filing a sensible bug though :). So what it really boils down to is that I think we need to provide a way to help users help us by providing the ability to interact with people (Yea, #gentoo works up to a point) that can assist with basic trouble-shooting to point people towards that which could be the problem to help with filing better bug reports. I've been hunting a graphics terminal corruption issue with urxvt now, and in the man page you get this: [Please note that many X servers (and libXft) are buggy with respect to "-depth 32" and/or alpha channels, and will cause all sorts of graphical corruption. This is harmless, but we can't do anything about this, so watch out] So where to from here? Researching that it seems most other similar reports relate to 4th-gen intel graphics ... heck, this was even attributed to pango at some point, and some other dock launcher which name I can't remember now. I've now explicitly set depth to 24 so I'll know soon enough if this is the issue. To confuse the matter even more, I've had the same corruption using aterm, and in xterm as well. But it *only* seems to happen with terminal emulators. Then there is the issue I described above. Currently I have another two or three *desktop* related issues that plague me, none of which are easy to point where the bug may actually be, so to file a bug given this is hard. Anyway, count me in on bugday if I can be there at all. This should be interesting. Looking at the previous bug day there is one thing I don't see: How does this approach work? In oher words, the lead-up and organization seems to be fairly well spelt out - but how does it work on the day? When does it actually start? Or is this a world-wide rolling time GMT+12 starts waking up until GMT-12 starts heading to bed? This is the opportunity to market the event. Kind Regards, Jaco > > Aisha > >> Guessing #gentoo may also be of help in regards to the above, so this is >> really just a suggestion. Yes, it will generate more bugs, but >> hopefully the concept will allow for creating targeted bugs rather than >> overly generic difficult to trouble-shoot bugs. >> >> Kind Regards, >> Jaco >> >> On 2020/06/11 14:41, Aisha Tammy wrote: >> >>> # Gentoo BugDay >>> >>> >>> >>> >>> Come join us over at #gentoo-bugday on freenode IRC on the first Saturday >>> of every month >>> >>> >>> to squash bugs and make Gentoo a bit more awesome. >>> >>> >>> >>> >>> You don't need to be a Gentoo developer or even a coder to help us on >>> BugDay. >>> >>> >>> Our next BugDay is on 4th July 2020 and we have started making preparations >>> for >>> selecting and prioritizing bug categories for that day. >>> >>> >>> >>> ## Bug categories >>> >>> >>> >>> >>> The bug categories should be broad enough that there will be a lot of bugs >>> being >>> >>> targeted. >>> >>> >>> >>> >>> We keep a option poll open to everybody to help us narrow down the >>> categories of bugs to focus. >>> >>> >>> The opinion poll is there to get an input from everyone about how to best >>> tackle the >>> >>> >>> current bug situation and get an understanding of the community and >>> developer priorities. >>> >>> >>> >>> >>> The poll is open at https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/ >>> >>> >>> Be sure to vote in the poll to get your opinion heard. >>> >>> >>> >>> ## For developers >>> >>> >>> >>> >>> Even if you have never coded for Gentoo you can help us with your >>> experience. >>> >>> It's always valuable to have your experience to guide us. >>> >>> >>> >>> >>> Things to help with >>> >>> >>> - Find a related bug that piques your interest. >>> >>> >>> - Look at upstream if this has been reported to them. >>> >>> >>> - If not, make a bug report to the upstream developers. >>> >>> >>> - If they have already seen it, check if they have managed to patch it. >>> >>> >>> - If not, try to gather as much information as you can about the bug so that >>> >>> >>> it may help the developer tackling it. >>> >>> >>> - Alert us at #gentoo-bugday and interact with us to see if this can be >>> squashed. >>> >>> >>> >>> >>> ## For users >>> >>> >>> >>> >>> U
Re: [gentoo-dev] [RFC] Codec project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 10 Jun 2020 20:25:20 +0200 Michał Górny wrote: > Hi, > > Let's split this from [1] as I suppose having it in middle of > high-noise 'up for grabs' might prevent some interested people from > seeing it. > > The general purpose of codec project [2] is to maintain core libraries > for various multimedia format encoder/decoder libraries. It's like > gfx+sound+video except only for core packages and not every possible > single viewer, player, editor, frontend... Not that I'm against the idea, but seeing the project has 3 members already and none of them were part of the gfx+sound+video projects AFAIK, I am wondering if this is the proper way to do it. What about /j #gentoo-media, discuss, join the current projects, get a few things done (there is a lot of choice there ;) ), maybe orphan unmaintained players/viewers, or check if they are maintained and hand them to a specific maintainer, and then see about merging or splitting all those projects *after* gaining experience and knowledge about the peculiarities of some of those packages ? Speaking about sound&video, I am under the impression that the library, or "codec" part, of those projects is far less lacking manpower than the "leaf" part (players, frontends, etc.). Alexis. -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXuOSHQAKCRAOJUi7xgfl rp68AP9hzTRmZoDoderMZkLt5HsRCcfwemcVl2kvytPInVPvxQD+LnBcBOGaQy7Y 9iOhbi0fkwt9YBoq4rsBk3rzguHjvm0= =f3JV -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On Fri, 12 Jun 2020 02:04:51 -0700
Georgy Yakovlev wrote:
> +#cargo_src_configure --no-default-features
Looking at the source, I don't see how this is passed from this command to
anything.
> + # transform array from simple feature list
> + # to multiple cargo args:
> + # --features feature1 --features feature2 ...
> + readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
Is this really necessary?
> cargo --features "feature1 feature2"
is perfectly legal.
pgpryNPG16yA7.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug
On 6/12/20 6:55 AM, Jaco Kroon wrote: > Hi, > > Can we possibly include the concept of "helping to file bug reports" here? > > For example, I've got an issue (which hasn't annoyed me just quite > enough yet to put effort in) where on bootup after xdm init script > starts it takes ~2 minutes before slim login is displayed. But I don't > know enough of the workings of that to even understand if this is an > Xorg or slim (or dbus) bug ... > BugDay is not for creating bugs, its for squashing them. You can create the bugs today and then if it is in one of the top voted categories (old bugs, in this case) you might be able to convince interested devs to target your specific ones. Aisha > Guessing #gentoo may also be of help in regards to the above, so this is > really just a suggestion. Yes, it will generate more bugs, but > hopefully the concept will allow for creating targeted bugs rather than > overly generic difficult to trouble-shoot bugs. > > Kind Regards, > Jaco > > On 2020/06/11 14:41, Aisha Tammy wrote: > >> # Gentoo BugDay >> >> >> >> >> Come join us over at #gentoo-bugday on freenode IRC on the first Saturday of >> every month >> >> >> to squash bugs and make Gentoo a bit more awesome. >> >> >> >> >> You don't need to be a Gentoo developer or even a coder to help us on BugDay. >> >> >> Our next BugDay is on 4th July 2020 and we have started making preparations >> for >> selecting and prioritizing bug categories for that day. >> >> >> >> ## Bug categories >> >> >> >> >> The bug categories should be broad enough that there will be a lot of bugs >> being >> >> targeted. >> >> >> >> >> We keep a option poll open to everybody to help us narrow down the >> categories of bugs to focus. >> >> >> The opinion poll is there to get an input from everyone about how to best >> tackle the >> >> >> current bug situation and get an understanding of the community and >> developer priorities. >> >> >> >> >> The poll is open at https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/ >> >> >> Be sure to vote in the poll to get your opinion heard. >> >> >> >> ## For developers >> >> >> >> >> Even if you have never coded for Gentoo you can help us with your experience. >> >> It's always valuable to have your experience to guide us. >> >> >> >> >> Things to help with >> >> >> - Find a related bug that piques your interest. >> >> >> - Look at upstream if this has been reported to them. >> >> >> - If not, make a bug report to the upstream developers. >> >> >> - If they have already seen it, check if they have managed to patch it. >> >> >> - If not, try to gather as much information as you can about the bug so that >> >> >> it may help the developer tackling it. >> >> >> - Alert us at #gentoo-bugday and interact with us to see if this can be >> squashed. >> >> >> >> >> ## For users >> >> >> >> >> Users are one of the most important part of Gentoo and this is the occasion >> for >> >> >> them to talk the developers and make your bugs looked at. >> >> >> >> >> Take a look at the categories for BugDay at the poll link and the final >> BugDay >> >> >> wiki page >> >> >> - Find a related bug that you have experienced and has not been fixed yet >> >> >> - Try to see how it can be reproduced.Gnome not doing proper logins on you >> laptop? >> >> >> - The related bug reports have been ignored for months you say? >> >> >> >> >> Come poke us about these bugs at #gentoo-bugday on the freenode IRC and we >> will >> begin squashing any of >> >> those that are pending. >> >> >> >> >> ## Whats in it for me? >> >> >> >> >> Bragging rights, permanently being listed on the charts of BugDay, sense of >> entitlement. >> >> >> >> Any person who helps us solve valid problems will be given the honor of >> being listed on >> >> the page. >> >> Even users who help related bugs and find links which make our problem >> solving easier >> >> will be put on a pedestal. >> >> >> >> ## Contributors >> >> >> >> >> Thanks a lot to jstein@ for being the gracious organizer and making sure >> everything >> >> >> goes smoothly. >> >> >> >> >> And special thanks to contributors who have worked on our previous BugDays. >> >> Past contributors: >> >> >> - https://wiki.gentoo.org/wiki/Bugday_2020-06-06 >> >
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 12/06/2020 11:04, Georgy Yakovlev wrote: +# cargo_src_configure --no-default-features Shall we default in not-defaulting so we can spare some boilerplate? lu
Re: [gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support
On 12/06/2020 05:15, Georgy Yakovlev wrote: This will also allow me to start adding cross support to cargo.eclass with new cross-friendly variables. experimental cross support landed in rust-1.44.0 today [1] Yes please :) lu
Re: [gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug
Hi, Can we possibly include the concept of "helping to file bug reports" here? For example, I've got an issue (which hasn't annoyed me just quite enough yet to put effort in) where on bootup after xdm init script starts it takes ~2 minutes before slim login is displayed. But I don't know enough of the workings of that to even understand if this is an Xorg or slim (or dbus) bug ... Guessing #gentoo may also be of help in regards to the above, so this is really just a suggestion. Yes, it will generate more bugs, but hopefully the concept will allow for creating targeted bugs rather than overly generic difficult to trouble-shoot bugs. Kind Regards, Jaco On 2020/06/11 14:41, Aisha Tammy wrote: > # Gentoo BugDay > > > > > Come join us over at #gentoo-bugday on freenode IRC on the first Saturday of > every month > > > to squash bugs and make Gentoo a bit more awesome. > > > > > You don't need to be a Gentoo developer or even a coder to help us on BugDay. > > > Our next BugDay is on 4th July 2020 and we have started making preparations > for > selecting and prioritizing bug categories for that day. > > > > ## Bug categories > > > > > The bug categories should be broad enough that there will be a lot of bugs > being > > targeted. > > > > > We keep a option poll open to everybody to help us narrow down the categories > of bugs to focus. > > > The opinion poll is there to get an input from everyone about how to best > tackle the > > > current bug situation and get an understanding of the community and developer > priorities. > > > > > The poll is open at https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/ > > > Be sure to vote in the poll to get your opinion heard. > > > > ## For developers > > > > > Even if you have never coded for Gentoo you can help us with your experience. > > It's always valuable to have your experience to guide us. > > > > > Things to help with > > > - Find a related bug that piques your interest. > > > - Look at upstream if this has been reported to them. > > > - If not, make a bug report to the upstream developers. > > > - If they have already seen it, check if they have managed to patch it. > > > - If not, try to gather as much information as you can about the bug so that > > > it may help the developer tackling it. > > > - Alert us at #gentoo-bugday and interact with us to see if this can be > squashed. > > > > > ## For users > > > > > Users are one of the most important part of Gentoo and this is the occasion > for > > > them to talk the developers and make your bugs looked at. > > > > > Take a look at the categories for BugDay at the poll link and the final BugDay > > > wiki page > > > - Find a related bug that you have experienced and has not been fixed yet > > > - Try to see how it can be reproduced.Gnome not doing proper logins on you > laptop? > > > - The related bug reports have been ignored for months you say? > > > > > Come poke us about these bugs at #gentoo-bugday on the freenode IRC and we > will > begin squashing any of > > those that are pending. > > > > > ## Whats in it for me? > > > > > Bragging rights, permanently being listed on the charts of BugDay, sense of > entitlement. > > > > Any person who helps us solve valid problems will be given the honor of being > listed on > > the page. > > Even users who help related bugs and find links which make our problem > solving easier > > will be put on a pedestal. > > > > ## Contributors > > > > > Thanks a lot to jstein@ for being the gracious organizer and making sure > everything > > > goes smoothly. > > > > > And special thanks to contributors who have worked on our previous BugDays. > > Past contributors: > > > - https://wiki.gentoo.org/wiki/Bugday_2020-06-06 >
[gentoo-dev] Re: [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 6/12/20 2:04 AM, Georgy Yakovlev wrote:
> simple src_configure implementation inspired by cmake.eclass
>
> Closes: https://bugs.gentoo.org/721936
>
> Signed-off-by: Georgy Yakovlev
> ---
> eclass/cargo.eclass | 51 ++---
> 1 file changed, 44 insertions(+), 7 deletions(-)
>
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..b084e082730 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -23,7 +23,7 @@ esac
>
> inherit multiprocessing toolchain-funcs
>
> -EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
> +EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
>
> IUSE="${IUSE} debug"
>
> @@ -35,6 +35,24 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
> # Allows overriding the default cwd to run cargo install from
> : ${CARGO_INSTALL_PATH:=.}
>
> +# @VARIABLE: myfeatures
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Optional cargo features defined as bash array. Should be defined before
> calling
> +# src_configure.
> +# Example for package that has x11 and wayland as features.
> +# Also disables default features, as optional parameter is passed.
> +# @CODE
> +# src_configure() {
> +#local myfeatures=(
> +#$(usex X x11 '')
> +#$(usev wayland)
> +#)
> +#
> +#cargo_src_configure --no-default-features
> +# }
> +# @CODE
> +
> # @FUNCTION: cargo_crate_uris
> # @DESCRIPTION:
> # Generates the URIs to put in SRC_URI to help fetch dependencies.
> @@ -113,6 +131,7 @@ cargo_live_src_unpack() {
> mkdir -p "${S}" || die
>
> pushd "${S}" > /dev/null || die
> + # need to specify CARGO_HOME before cargo_gen_config fired
> CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
> CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
> popd > /dev/null || die
> @@ -152,6 +171,26 @@ cargo_gen_config() {
> EOF
> # honor NOCOLOR setting
> [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color =
> 'never'" >> "${ECARGO_HOME}/config"
> +
> + export CARGO_HOME="${ECARGO_HOME}"
> +}
> +
> +# @FUNCTION: cargo_src_configure
> +# @DESCRIPTION:
> +# Configure cargo package features
> +cargo_src_configure() {
> + debug-print-function ${FUNCNAME} "$@"
> +
> + [[ -z ${myfeatures} ]] && declare -a myfeatures=()
> + local myfeaturestype=$(declare -p myfeatures 2>&-)
> + if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
> + die "myfeatures must be declared as array"
> + fi
> +
> + # transform array from simple feature list
> + # to multiple cargo args:
> + # --features feature1 --features feature2 ...
> + readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
missed ${@}, fixed locally, this should be,
readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } ${@} )
> }
>
> # @FUNCTION: cargo_src_compile
> @@ -160,11 +199,9 @@ cargo_gen_config() {
> cargo_src_compile() {
> debug-print-function ${FUNCNAME} "$@"
>
> - export CARGO_HOME="${ECARGO_HOME}"
> -
> tc-export AR CC
>
> - cargo build $(usex debug "" --release) "$@" \
> + cargo build $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
> || die "cargo build failed"
> }
>
> @@ -174,8 +211,8 @@ cargo_src_compile() {
> cargo_src_install() {
> debug-print-function ${FUNCNAME} "$@"
>
> - cargo install --path ${CARGO_INSTALL_PATH} \
> - --root="${ED}/usr" $(usex debug --debug "") "$@" \
> + cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
> + $(usex debug --debug "") ${ECARGO_FEATURES[@]} "$@" \
> || die "cargo install failed"
> rm -f "${ED}/usr/.crates.toml"
> rm -f "${ED}/usr/.crates2.json"
> @@ -189,7 +226,7 @@ cargo_src_install() {
> cargo_src_test() {
> debug-print-function ${FUNCNAME} "$@"
>
> - cargo test $(usex debug "" --release) "$@" \
> + cargo test $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
> || die "cargo test failed"
> }
>
>
[gentoo-dev] Re: [PATCH 2/2] x11-terms/alacritty: use new cargo_src_configure
On 6/12/20 2:04 AM, Georgy Yakovlev wrote:
> Signed-off-by: Georgy Yakovlev
> ---
> x11-terms/alacritty/alacritty-0.4.3.ebuild | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/x11-terms/alacritty/alacritty-0.4.3.ebuild
> b/x11-terms/alacritty/alacritty-0.4.3.ebuild
> index ac4d768d09b..2efc1a6dd0a 100644
> --- a/x11-terms/alacritty/alacritty-0.4.3.ebuild
> +++ b/x11-terms/alacritty/alacritty-0.4.3.ebuild
> @@ -328,19 +328,20 @@ src_unpack() {
> }
>
> src_configure() {
> - myfeatures=(
> + local myfeatures=(
> $(usex X x11 '')
> $(usev wayland)
> )
> + cargo_src_configure
> }
>
> src_compile() {
> cd alacritty || die
> - cargo_src_compile ${myfeatures:+--features "${myfeatures[*]}"}
> --no-default-features
> + cargo_src_compile --no-default-features
> }
^ --no-default-features should be passed to configure, missed it before
push, fixed locally.
>
> src_install() {
> - CARGO_INSTALL_PATH="alacritty" cargo_src_install
> ${myfeatures:+--features "${myfeatures[*]}"} --no-default-features
> + CARGO_INSTALL_PATH="alacritty" cargo_src_install
>
> newman extra/alacritty.man alacritty.1
>
> @@ -368,5 +369,5 @@ src_install() {
>
> src_test() {
> cd alacritty || die
> - cargo_src_test ${myfeatures:+--features "${myfeatures[*]}"}
> --no-default-features
> + cargo_src_test
> }
>
[gentoo-dev] PATCH: cargo.eclass src_configure function
Add simple src_configure implementation, based on cmake.eclass. 2nd patch is an example of migrated ebuild.
[gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
simple src_configure implementation inspired by cmake.eclass
Closes: https://bugs.gentoo.org/721936
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 51 ++---
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ad90a0c7dd8..b084e082730 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -23,7 +23,7 @@ esac
inherit multiprocessing toolchain-funcs
-EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
+EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
IUSE="${IUSE} debug"
@@ -35,6 +35,24 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
# Allows overriding the default cwd to run cargo install from
: ${CARGO_INSTALL_PATH:=.}
+# @VARIABLE: myfeatures
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Optional cargo features defined as bash array. Should be defined before
calling
+# src_configure.
+# Example for package that has x11 and wayland as features.
+# Also disables default features, as optional parameter is passed.
+# @CODE
+# src_configure() {
+# local myfeatures=(
+# $(usex X x11 '')
+# $(usev wayland)
+# )
+#
+# cargo_src_configure --no-default-features
+# }
+# @CODE
+
# @FUNCTION: cargo_crate_uris
# @DESCRIPTION:
# Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -113,6 +131,7 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
pushd "${S}" > /dev/null || die
+ # need to specify CARGO_HOME before cargo_gen_config fired
CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
@@ -152,6 +171,26 @@ cargo_gen_config() {
EOF
# honor NOCOLOR setting
[[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color =
'never'" >> "${ECARGO_HOME}/config"
+
+ export CARGO_HOME="${ECARGO_HOME}"
+}
+
+# @FUNCTION: cargo_src_configure
+# @DESCRIPTION:
+# Configure cargo package features
+cargo_src_configure() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ [[ -z ${myfeatures} ]] && declare -a myfeatures=()
+ local myfeaturestype=$(declare -p myfeatures 2>&-)
+ if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
+ die "myfeatures must be declared as array"
+ fi
+
+ # transform array from simple feature list
+ # to multiple cargo args:
+ # --features feature1 --features feature2 ...
+ readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
}
# @FUNCTION: cargo_src_compile
@@ -160,11 +199,9 @@ cargo_gen_config() {
cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
- export CARGO_HOME="${ECARGO_HOME}"
-
tc-export AR CC
- cargo build $(usex debug "" --release) "$@" \
+ cargo build $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo build failed"
}
@@ -174,8 +211,8 @@ cargo_src_compile() {
cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
- cargo install --path ${CARGO_INSTALL_PATH} \
- --root="${ED}/usr" $(usex debug --debug "") "$@" \
+ cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
+ $(usex debug --debug "") ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
rm -f "${ED}/usr/.crates2.json"
@@ -189,7 +226,7 @@ cargo_src_install() {
cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
- cargo test $(usex debug "" --release) "$@" \
+ cargo test $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo test failed"
}
--
2.27.0
[gentoo-dev] [PATCH 2/2] x11-terms/alacritty: use new cargo_src_configure
Signed-off-by: Georgy Yakovlev
---
x11-terms/alacritty/alacritty-0.4.3.ebuild | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/x11-terms/alacritty/alacritty-0.4.3.ebuild
b/x11-terms/alacritty/alacritty-0.4.3.ebuild
index ac4d768d09b..2efc1a6dd0a 100644
--- a/x11-terms/alacritty/alacritty-0.4.3.ebuild
+++ b/x11-terms/alacritty/alacritty-0.4.3.ebuild
@@ -328,19 +328,20 @@ src_unpack() {
}
src_configure() {
- myfeatures=(
+ local myfeatures=(
$(usex X x11 '')
$(usev wayland)
)
+ cargo_src_configure
}
src_compile() {
cd alacritty || die
- cargo_src_compile ${myfeatures:+--features "${myfeatures[*]}"}
--no-default-features
+ cargo_src_compile --no-default-features
}
src_install() {
- CARGO_INSTALL_PATH="alacritty" cargo_src_install
${myfeatures:+--features "${myfeatures[*]}"} --no-default-features
+ CARGO_INSTALL_PATH="alacritty" cargo_src_install
newman extra/alacritty.man alacritty.1
@@ -368,5 +369,5 @@ src_install() {
src_test() {
cd alacritty || die
- cargo_src_test ${myfeatures:+--features "${myfeatures[*]}"}
--no-default-features
+ cargo_src_test
}
--
2.27.0
