From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v9 8/8] cargo: new package
Date: Thu, 28 Dec 2017 22:32:38 +0100 [thread overview]
Message-ID: <20171228223238.69698252@windsurf> (raw)
In-Reply-To: <20171228155146.18193-9-eric.le.bihan.dev@free.fr>
Hello,
On Thu, 28 Dec 2017 16:51:46 +0100, Eric Le Bihan wrote:
> This new package provides Cargo, the Rust official package manager.
> Cargo is written in Rust and uses Cargo as its build system. It also
> depends on other Rust packages.
>
> Normally, a previously installed version of Cargo would be used to:
>
> 1. Fetch the dependencies.
> 2. Build the new version of Cargo, using the available Rust compiler.
>
> But the fetching step prevents offline builds. So instead two features
> of Cargo are levelled: vendoring [1] and local registry.
Did you want to say "leveraged" instead of "levelled" ?
> diff --git a/package/cargo/Config.in.host b/package/cargo/Config.in.host
> new file mode 100644
> index 0000000000..0f1ca305c6
> --- /dev/null
> +++ b/package/cargo/Config.in.host
> @@ -0,0 +1,8 @@
> +config BR2_PACKAGE_HOST_CARGO
> + bool "host cargo"
> + depends on BR2_PACKAGE_HAS_HOST_RUSTC
> + help
> + Cargo is the package manager for the Rust programming
> + language.
> +
> + https://crates.io/
How would "host cargo" be used in the context of Buildroot ? Would it
be used by packages that are written in Rust as part of their build
process ? What would such packages look like ?
> diff --git a/package/cargo/cargo.hash b/package/cargo/cargo.hash
> new file mode 100644
> index 0000000000..2b2ae43f6b
> --- /dev/null
> +++ b/package/cargo/cargo.hash
> @@ -0,0 +1,4 @@
> +# Locally generated
> +sha256 f4bbe2a8719dbb8da20842235093f7f70f034d01633189e83f75897d68cd274f cargo-0.23.0.tar.gz
> +sha512 9060ec6e67b54f7fad7da8dd8450dd051d62b3f8ed4606196fc238a98beba1c3b43087c787f35d012d9b641c8572e70f50b95b0e01fdd75ed82932b6e6efbbf0 cargo-0.23.0-vendor.tar.xz
> +sha256 dc7240d60a869fa24a68c8734fb7c810c27cca0a6dad52df6279865e4e8e7fae rust-installer-4f994850808a572e2cc8d43f968893c8e942e9bf.tar.gz
Why are you using sha256 sometimes, and sha512 sometimes? Seems like
for the cargo-0.23.0-vendor tarball, the hash is not exactly locally
generated, but really comes from upstream.
> +HOST_CARGO_DEPENDENCIES = \
> + host-cmake \
Do you need host-cmake absolutely here, or can you use
$(BR2_CMAKE_HOST_DEPENDENCY) instead ?
> + host-pkgconf \
> + host-openssl \
> + host-libhttpparser \
> + host-libssh2 \
> + host-libcurl \
> + host-rustc \
> + host-cargo-bin
> +
> +HOST_CARGO_SNAP_BIN = $(HOST_CARGO_BIN_DIR)/cargo/bin/cargo
> +HOST_CARGO_HOME = $(HOST_DIR)/share/cargo
> +
> +define HOST_CARGO_EXTRACT_DEPS
> + @mkdir -p $(@D)/vendor
> + $(call suitable-extractor,$(CARGO_DEPS_SOURCE)) \
> + $(DL_DIR)/$(CARGO_DEPS_SOURCE) | \
> + $(TAR) --strip-components=1 -C $(@D)/vendor $(TAR_OPTIONS) -
> +endef
> +
> +HOST_CARGO_POST_EXTRACT_HOOKS += HOST_CARGO_EXTRACT_DEPS
> +
> +define HOST_CARGO_EXTRACT_INSTALLER
> + @mkdir -p $(@D)/src/rust-installer
> + $(call suitable-extractor,$(CARGO_INSTALLER_SOURCE)) \
> + $(DL_DIR)/$(CARGO_INSTALLER_SOURCE) | \
> + $(TAR) --strip-components=1 -C $(@D)/src/rust-installer $(TAR_OPTIONS) -
> +endef
> +
> +HOST_CARGO_POST_EXTRACT_HOOKS += HOST_CARGO_EXTRACT_INSTALLER
> +
> +define HOST_CARGO_SETUP_DEPS
> + mkdir -p $(@D)/.cargo
> + ( \
> + echo "[source.crates-io]"; \
> + echo "registry = 'https://github.com/rust-lang/crates.io-index'"; \
> + echo "replace-with = 'vendored-sources'"; \
> + echo "[source.vendored-sources]"; \
> + echo "directory = '$(@D)/vendor'"; \
> + ) > $(@D)/.cargo/config
> +endef
> +
> +HOST_CARGO_PRE_CONFIGURE_HOOKS += HOST_CARGO_SETUP_DEPS
> +
> +HOST_CARGO_SNAP_OPTS = --release
> +HOST_CARGO_SNAP_OPTS += $(if $(VERBOSE),--verbose)
A single assignment would be prettier:
HOST_CARGO_SNAP_OPTS = \
--release \
$(if $(VERBOSE),--verbose)
> +HOST_CARGO_ENV = \
> + RUSTFLAGS="-Clink-arg=-Wl,-rpath,$(HOST_DIR)/lib" \
> + CARGO_HOME=$(HOST_DIR)/share/cargo
Why don't you use $(HOST_CARGO_HOME) here ?
> +define HOST_CARGO_BUILD_CMDS
> + (cd $(@D); $(HOST_MAKE_ENV) $(HOST_CARGO_ENV) $(HOST_CARGO_SNAP_BIN) \
> + build $(HOST_CARGO_SNAP_OPTS))
> +endef
> +
> +define HOST_CARGO_INSTALL_CMDS
> + $(INSTALL) -d -m 0755 $(HOST_DIR)/bin
This is not needed, just use the -D option in the command command
installing the cargo binary.
> + $(INSTALL) -m 0755 $(@D)/target/release/cargo $(HOST_DIR)/bin/cargo
> +endef
> +
> +define HOST_CARGO_INSTALL_CONF_FILE
> + $(INSTALL) -D package/cargo/config.in \
> + $(HOST_DIR)/share/cargo/config
> + $(SED) 's/@RUST_TARGET_NAME@/$(RUST_TARGET_NAME)/' \
> + $(HOST_DIR)/share/cargo/config
> + $(SED) 's/@CROSS_PREFIX@/$(notdir $(TARGET_CROSS))/' \
> + $(HOST_DIR)/share/cargo/config
This should be moved inside HOST_CARGO_INSTALL_CMDS, there is no need
for a separate post-install hook.
Also, I'm wondering of your choice between generating config files from
the .mk file, or having a template that gets tweaked using SED. In this
cargo.mk, you are producing a 5 lines file in HOST_CARGO_SETUP_DEPS
where only a single value varies (and would need to be tweaked with
sed). But on the other hand, you create a two lines share/cargo/config
file from a template. Perhaps we should settle on one or the other
solution ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-12-28 21:32 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
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 [this message]
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=20171228223238.69698252@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.