Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v9 2/8] rust-bin: new package
Date: Thu, 28 Dec 2017 21:37:02 +0100	[thread overview]
Message-ID: <20171228213702.469a4358@windsurf> (raw)
In-Reply-To: <20171228155146.18193-3-eric.le.bihan.dev@free.fr>

Hello,

On Thu, 28 Dec 2017 16:51:40 +0100, Eric Le Bihan wrote:
> This package provides a pre-built version of rustc, the compiler for the
> Rust programming language, fetched from the upstream project.
> 
> A pre-built version of the standard library for the host as well as one
> for the chosen target are also fetched and installed.

I was wondering if a separate package could be used to install the
standard library, in order to avoid the extra downloads and custom
extract step.

One possibility would be to have a rust-std-bin package, which rust-bin
depends on. The target version of rust-std-bin would install the target
libraries, while the host version would install the host libraries. The
weird thing is that the target libraries are installed in $(HOST_DIR),
while one would expect them to be in $(STAGING_DIR). Is this something
we can tell rustc about perhaps ?

Even if we keep the single package approach, having the target
libraries in $(STAGING_DIR) would be more logical. But that's a soft
requirement, so if it's too tedious to achieve with rustc, we can live
with them being in HOST_DIR.

> diff --git a/package/rust-bin/rust-bin.mk b/package/rust-bin/rust-bin.mk
> new file mode 100644
> index 0000000000..29f94b7f2d
> --- /dev/null
> +++ b/package/rust-bin/rust-bin.mk
> @@ -0,0 +1,63 @@
> +################################################################################
> +#
> +# rust-bin
> +#
> +################################################################################
> +
> +RUST_BIN_VERSION = 1.22.1
> +RUST_BIN_SITE = https://static.rust-lang.org/dist
> +RUST_BIN_LICENSE = Apache-2.0 or MIT
> +RUST_BIN_LICENSE_FILES = LICENSE-APACHE LICENSE-MIT
> +
> +HOST_RUST_BIN_PROVIDES = host-rustc
> +
> +HOST_RUST_BIN_SOURCE = rustc-$(RUST_BIN_VERSION)-$(RUST_HOST_NAME).tar.xz
> +HOST_RUST_BIN_LIBSTD_SOURCES = \
> +	rust-std-$(RUST_BIN_VERSION)-$(RUST_HOST_NAME).tar.xz \
> +	rust-std-$(RUST_BIN_VERSION)-$(RUST_TARGET_NAME).tar.xz
> +
> +HOST_RUST_BIN_EXTRA_DOWNLOADS = $(HOST_RUST_BIN_LIBSTD_SOURCES)

Assuming we keep the single package approach, then why not use
HOST_RUST_BIN_EXTRA_DOWNLOADS directly ? HOST_RUST_BIN_LIBSTD_SOURCES
looks a bit useless.

> +HOST_RUST_BIN_LIBSTD_HOST_PREFIX = rust-std-$(RUST_BIN_VERSION)-$(RUST_HOST_NAME)/rust-std-$(RUST_HOST_NAME)
> +
> +define HOST_RUST_BIN_LIBSTD_EXTRACT
> +	mkdir -p $(@D)/std
> +	for file in $(addprefix $(DL_DIR)/,$(HOST_RUST_BIN_LIBSTD_SOURCES)); do \
> +		$(TAR) -C $(@D)/std -xJf $${file}; \

This would benefit from using $(foreach ...) and should use
suitable-extractor. Something like (untested):

	$(foreach f,$(HOST_RUST_BIN_EXTRA_DOWNLOADS), \
		$(call suitable-extractor,$(f)) $(DL_DIR)/$(f) | \
			$(TAR) -C $(@D)/std $(TAR_OPTIONS) -
	)

> +	done
> +	(\
> +		cd $(@D)/rustc/lib/rustlib; \
> +		ln -sf ../../../std/$(HOST_RUST_BIN_LIBSTD_HOST_PREFIX)/lib/rustlib/$(RUST_HOST_NAME) \
> +	)

There's no need for this command to run in a sub-shell, so:

	cd $(@D)/rustc/lib/rustlib; \
		ln -sf ../../../std/$(HOST_RUST_BIN_LIBSTD_HOST_PREFIX)/lib/rustlib/$(RUST_HOST_NAME)

should be sufficient.

> +endef
> +
> +HOST_RUST_BIN_POST_EXTRACT_HOOKS += HOST_RUST_BIN_LIBSTD_EXTRACT
> +
> +HOST_RUST_BIN_INSTALL_OPTS = \
> +	--prefix=$(HOST_DIR) \
> +	--disable-ldconfig
> +
> +ifeq ($(BR2_PACKAGE_HOST_RUST_BIN),y)

Why do you have this conditional ? If the package isn't built, then
those definitions aren't used anyway.

The rest looks good to me. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2017-12-28 20:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-28 15:51 [Buildroot] [PATCH v9 0/8] Add support for the Rust programming Eric Le Bihan
2017-12-28 15:51 ` [Buildroot] [PATCH v9 1/8] rustc: new virtual package Eric Le Bihan
2017-12-28 16:27   ` Thomas Petazzoni
2018-01-01 16:11     ` Eric Le Bihan
2017-12-28 15:51 ` [Buildroot] [PATCH v9 2/8] rust-bin: new package Eric Le Bihan
2017-12-28 20:37   ` Thomas Petazzoni [this message]
2018-01-01 20:13     ` Eric Le Bihan
2017-12-28 15:51 ` [Buildroot] [PATCH v9 3/8] cargo-bin: " Eric Le Bihan
2017-12-28 20:38   ` Thomas Petazzoni
2018-01-01 20:14     ` Eric Le Bihan
2017-12-28 15:51 ` [Buildroot] [PATCH v9 4/8] rust: " Eric Le Bihan
2017-12-28 21:08   ` Thomas Petazzoni
2018-01-01 20:23     ` Eric Le Bihan
2017-12-28 15:51 ` [Buildroot] [PATCH v9 5/8] libssh2: add host variant Eric Le Bihan
2017-12-28 21:11   ` Thomas Petazzoni
2017-12-28 15:51 ` [Buildroot] [PATCH v9 6/8] libhttpparser: " Eric Le Bihan
2017-12-28 21:19   ` Thomas Petazzoni
2017-12-28 15:51 ` [Buildroot] [PATCH v9 7/8] libcurl: " Eric Le Bihan
2017-12-28 21:19   ` Thomas Petazzoni
2017-12-28 15:51 ` [Buildroot] [PATCH v9 8/8] cargo: new package Eric Le Bihan
2017-12-28 21:32   ` Thomas Petazzoni
2018-01-02 17:49     ` Eric Le Bihan
2017-12-28 16:21 ` [Buildroot] [PATCH v9 0/8] Add support for the Rust programming Thomas Petazzoni
2017-12-28 17:52   ` Eric Le Bihan
2017-12-28 21:36     ` Thomas Petazzoni
2018-01-02 17:51       ` Eric Le Bihan
2018-01-18  7:48       ` Eric Le Bihan
2018-01-18  8:03         ` Thomas Petazzoni
2018-01-18 22:41           ` Eric Le Bihan
2018-01-19  8:03             ` Thomas Petazzoni
2018-01-22 21:57               ` Arnout Vandecappelle

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=20171228213702.469a4358@windsurf \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /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