From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: Dirkjan Ochtman <djc@gentoo.org>
Subject: Re: [gentoo-dev] [PATCH] eclass: add rust-toolchain.eclass
Date: Thu, 18 Oct 2018 17:22:08 +0200 [thread overview]
Message-ID: <1539876128.1510.8.camel@gentoo.org> (raw)
In-Reply-To: <20181015194135.24123-1-djc@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 6052 bytes --]
On Mon, 2018-10-15 at 21:41 +0200, Dirkjan Ochtman wrote:
> Signed-off-by: Dirkjan Ochtman <djc@gentoo.org>
> ---
> eclass/rust-toolchain.eclass | 120 +++++++++++++++++++++++++++++++++++
> 1 file changed, 120 insertions(+)
> create mode 100644 eclass/rust-toolchain.eclass
I'm sorry that I haven't managed to find time to review this in 3 days.
>
> diff --git a/eclass/rust-toolchain.eclass b/eclass/rust-toolchain.eclass
> new file mode 100644
> index 00000000000..d09db264fc3
> --- /dev/null
> +++ b/eclass/rust-toolchain.eclass
> @@ -0,0 +1,120 @@
> +# Copyright 1999-2018 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: rust-toolchain.eclass
> +# @MAINTAINER:
> +# Rust Project <rust@gentoo.org>
> +# @SUPPORTED_EAPIS: 6
This doesn't match the conditional below...
> +# @BLURB: helps map gentoo arches to rust ABIs
> +# @DESCRIPTION:
> +# This eclass contains a src_unpack default phase function, and
> +# helper functions, to aid in proper rust-ABI handling for various
> +# gentoo arches.
> +
> +case ${EAPI} in
> + 6) : ;;
> + 7) : ;;
...which permits 6 and 7.
> + *) die "EAPI=${EAPI:-0} is not supported" ;;
> +esac
> +
> +inherit multilib-build
> +
> +# @ECLASS-VARIABLE: RUST_TOOLCHAIN_BASEURL
> +# @DESCRIPTION:
> +# This variable specifies the base URL used by the
> +# rust_arch_uri and rust_all_arch_uris functions when
> +# generating the URI output list.
> +: ${RUST_TOOLCHAIN_BASEURL:=https://static.rust-lang.org/dist/}
> +
> +# @FUNCTION: rust_abi
> +# @USAGE: [CHOST-value]
> +# @DESCRIPTION:
> +# Outputs the Rust ABI name from a CHOST value, uses CHOST in the
> +# environment if none is specified.
> +
> +rust_abi() {
> + local CTARGET=${1:-${CHOST}}
You're mixing tab and space indent.
> + case ${CTARGET%%*-} in
> + aarch64*) echo aarch64-unknown-linux-gnu;;
> + mips64*) echo mips64-unknown-linux-gnuabi64;;
> + powerpc64le*) echo powerpc64le-unknown-linux-gnu;;
> + powerpc64*) echo powerpc64-unknown-linux-gnu;;
> + x86_64*) echo x86_64-unknown-linux-gnu;;
> + armv6j*s*) echo arm-unknown-linux-gnueabi;;
Substring match for a single letter is a horrible idea. It even fails
with one of standard CHOSTs we have: armv6j-unknown-linux-musleabihf.
> + armv6j*h*) echo arm-unknown-linux-gnueabihf;;
> + armv7a*h*) echo armv7-unknown-linux-gnueabihf;;
> + i?86*) echo i686-unknown-linux-gnu;;
> + mipsel*) echo mipsel-unknown-linux-gnu;;
> + mips*) echo mips-unknown-linux-gnu;;
> + powerpc*) echo powerpc-unknown-linux-gnu;;
> + s390x*) echo s390x-unknown-linux-gnu;;
> + *) echo ${CTARGET};;
> + esac
> +}
> +
> +# @FUNCTION: rust_all_abis
> +# @DESCRIPTION:
> +# Outputs a list of all the enabled Rust ABIs
> +rust_all_abis() {
> + if use multilib; then
USE=multilib is deprecated. Any new packages should be using ABI_*
flags directly.
> + local abi
> + local ALL_ABIS=()
> + for abi in $(multilib_get_enabled_abis); do
In fact, to what purpose are you inheriting multilib-build if you
completely ignore the new API and instead use obsolete multilib.eclass
functions directly?
> + ALL_ABIS+=( $(rust_abi $(get_abi_CHOST ${abi})) )
> + done
> + local abi_list
> + IFS=, eval 'abi_list=${ALL_ABIS[*]}'
The 'eval' here is absolutely unnecessary:
local IFS=,
echo "${ALL_ABIS[*]}"
> + echo ${abi_list}
> + else
> + rust_abi
> + fi
> +}
> +
> +# @FUNCTION: rust_arch_uri
> +# @USAGE: <rust-ABI> <base-uri> [alt-distfile-basename]
> +# @DESCRIPTION:
> +# Output the URI for use in SRC_URI, combining $RUST_TOOLCHAIN_BASEURL
> +# and the URI suffix provided in ARG2 with the rust ABI in ARG1, and
> +# optionally renaming to the distfile basename specified in ARG3.
Why are you using ARGn when you explicitly named the parameters above?
> +#
> +# @EXAMPLE:
> +# SRC_URI="amd64? (
> +# $(rust_arch_uri x86_64-unknown-linux-gnu rustc-${STAGE0_VERSION})
> +# )"
> +#
> +rust_arch_uri() {
> + if [ -n "$3" ]; then
Always use [[ ... ]] in bash.
> + echo "${RUST_TOOLCHAIN_BASEURL}${2}-${1}.tar.gz -> ${3}-${1}.tar.gz"
> + else
> + echo "${RUST_TOOLCHAIN_BASEURL}${2}-${1}.tar.gz"
Why not make this common, and just append "-> ..." when [[ -n ${3} ]]?
> + fi
> +}
> +
> +# @FUNCTION: rust_all_arch_uris
> +# @USAGE <base-uri> [alt-distfile-basename]
> +# @DESCRIPTION:
> +# Outputs the URIs for SRC_URI to help fetch dependencies, using a base URI
> +# provided as an argument. Optionally allows for distfile renaming via a specified
> +# basename.
> +#
> +# @EXAMPLE:
> +# SRC_URI="$(rust_all_arch_uris rustc-${STAGE0_VERSION})"
> +#
> +rust_all_arch_uris()
> +{
> + local uris=""
> + uris+="amd64? ( $(rust_arch_uri x86_64-unknown-linux-gnu "$@") ) "
> + uris+="arm? ( $(rust_arch_uri arm-unknown-linux-gnueabi "$@")
> + $(rust_arch_uri arm-unknown-linux-gnueabihf "$@")
> + $(rust_arch_uri armv7-unknown-linux-gnueabihf "$@") ) "
> + uris+="arm64? ( $(rust_arch_uri aarch64-unknown-linux-gnu "$@") ) "
> + uris+="mips? ( $(rust_arch_uri mips-unknown-linux-gnu "$@")
> + $(rust_arch_uri mipsel-unknown-linux-gnu "$@")
> + $(rust_arch_uri mips64-unknown-linux-gnuabi64 "$@") ) "
> + uris+="ppc? ( $(rust_arch_uri powerpc-unknown-linux-gnu "$@") ) "
> + uris+="ppc64? ( $(rust_arch_uri powerpc64-unknown-linux-gnu "$@")
> + $(rust_arch_uri powerpc64le-unknown-linux-gnu "$@") ) "
> + uris+="s390? ( $(rust_arch_uri s390x-unknown-linux-gnu "$@") ) "
> + uris+="x86? ( $(rust_arch_uri i686-unknown-linux-gnu "$@") ) "
> + echo "${uris}"
> +}
How are you going to deal with future versions having more/less
variants?
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
prev parent reply other threads:[~2018-10-18 15:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-15 19:41 [gentoo-dev] [PATCH] eclass: add rust-toolchain.eclass Dirkjan Ochtman
2018-10-18 15:22 ` Michał Górny [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1539876128.1510.8.camel@gentoo.org \
--to=mgorny@gentoo.org \
--cc=djc@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox