[Buildroot] [Patch v7 06/10] rust: new package
Eric Le Bihan
eric.le.bihan.dev at free.fr
Thu Sep 7 19:58:43 UTC 2017
Hi!
On 17-08-11 01:38:08, Arnout Vandecappelle wrote:
>
>
> On 23-07-17 10:12, Eric Le Bihan wrote:
> > This new package provides rustc, the compiler for the Rust programming
> > language, built from source.
> >
> > Currently, only the host variant is built.
> >
> > The Rust compiler uses LLVM as its backend: a copy of LLVM source code
> > is provided and CMake is used to build it. It is possible to use a
> > pre-built external copy. When LLVM/clang will be available in Buildroot,
> > it would be possible to benefit from this feature and thus decrease
> > build time.
> >
> > LLVM is configured to generate code for x86, ARM, PowerPC and MIPS
> > architectures.
> >
> > The Rust compiler uses Cargo as its build system and is written in Rust.
> > Therefore this package depends on cargo-bootstrap and rust-bootstrap.
> >
> > The internal build process is as follows:
> >
> > 1. rustc-stage0, provided by rust-bootstrap, is used to build
> > rustc-stage1.
> > 2. rust-stage1 builds the final Rust compiler (rust-stage2)
> > and the standard library for the host architecture.
>
> If rust-bootstrap is replaced by host-rustc-bin, then I think we could jump
> directly to stage2, right?
AFAIK, I do not think so.
> > 3. the standard library for the target architecture is built.
>
> And the source of the standard library is included in rustc-src.tar.xz, right?
Yes.
> So adding a rust-std package doesn't make much sense, I guess, only rust-std-bin.
As suggested previously, how about a rust-std virtual package? host-rust
would provide host-rustc and host-rust-std.
> [snip]
> > +define HOST_RUST_CONFIGURE_CMDS
> > + (cd $(@D); \
> > + echo '[build]' > config.toml; \
> > + echo 'target = ["$(RUST_TARGET_NAME)"]' >> config.toml; \
> > + echo 'cargo = "$(HOST_CARGO_BOOTSTRAP_DIR)/cargo/bin/cargo"' >> config.toml; \
> > + echo 'rustc = "$(HOST_RUST_BOOTSTRAP_DIR)/rustc/bin/rustc"' >> config.toml; \
>
> Is it really necessary to refer to the build directories? Can't we copy stuff
> to HOST_DIR and use it from there?
IHMO, these bootstrap binaries are "disposable" and not worth ending up
in $(HOST_DIR)/bin, hence the reference to the build directories. If
they do land in $(HOST_DIR)/bin, then they should be renamed to
{cargo,rustc}-bootstrap. Would it not confuse the user to have some many
versions of rustc/cargo in $(HOST_DIR)/bin?
> > + echo 'python = "$(HOST_DIR)/bin/python2"' >> config.toml; \
>
> The only reason to depend on host-python is because it needs python2 and not
> python3, right? I think we should just add in dependencies.sh a check for
> python2 instead of just python, so we can avoid building host-python. Or does it
> need python2.7.x?
The Python code looks compatible with Python 3.x. Needs some testing
though.
> > + echo 'submodules = false' >> config.toml; \
> > + echo 'vendor = true' >> config.toml; \
> > + echo 'compiler-docs = false' >> config.toml; \
> > + echo 'docs = false' >> config.toml; \
> > + echo 'verbose = $(HOST_RUST_VERBOSITY)' >> config.toml; \
> > + echo '[install]' >> config.toml; \
> > + echo 'prefix = "$(HOST_DIR)"' >> config.toml; \
> > + echo '[rust]' >> config.toml; \
> > + echo 'use-jemalloc = $(HOST_RUST_JEMALLOC_ENABLED)' >> config.toml; \
> > + echo '[target.$(RUST_TARGET_NAME)]' >> config.toml; \
> > + echo 'cc = "$(TARGET_CROSS)gcc"' >> config.toml; \
> > + echo 'cxx = "$(TARGET_CROSS)g++"' >> config.toml; \
>
> Doesn't rust/llvm have a way to specify the target CPU? Target optimisation
> options? Floating point?
I'll see if there are some options for this.
> > + echo $(HOST_RUST_JEMALLOC_CONF) >> config.toml; \
> > + )
>
> All these lines are quite ugly... Could be de-uglified a little bit by
> putting a single redirect after the closing )
Will do!
> > +endef
> > +
> > +define HOST_RUST_BUILD_CMDS
> > + (cd $(@D); $(HOST_MAKE_ENV) $(HOST_RUST_MAKE_ENV) python2 x.py \
> ^^^^^^^
> Make that an explicit
> $(HOST_DIR)/bin/python2
OK.
> HOST_RUST_MAKE_ENV is never assigned to, right?
Yes. It is useless. I will remove it.
> > + build $(HOST_RUST_BUILD_OPTS))
> > +endef
> > +
> > +define HOST_RUST_INSTALL_LIBSTD_TARGET
> > + (cd $(@D)/build/tmp/dist/rust-std-$(RUST_VERSION)-dev-$(RUST_TARGET_NAME); \
> > + ./install.sh \
> > + --prefix=$(HOST_DIR) \
> > + --docdir=$(HOST_DIR)/share/doc/rust \
> > + --libdir=$(HOST_DIR)/lib \
>
> So both the host and the target stdlib will go here? What if the host is a
> corei7 and target is atom?
Yes, I should handle the case where $(HOSTARCH) == $(ARCH).
> > + --mandir=$(HOST_DIR)/share/man \
> > + --disable-ldconfig)
> > +endef
> > +
> > +define HOST_RUST_INSTALL_CMDS
> > + (cd $(@D); $(HOST_MAKE_ENV) $(HOST_RUST_MAKE_ENV) python2 x.py \
> > + dist $(HOST_RUST_BUILD_OPTS))
> > + (cd $(@D); $(HOST_MAKE_ENV) $(HOST_RUST_MAKE_ENV) python2 x.py \
> > + install $(HOST_RUST_BUILD_OPTS))
> > + $(HOST_RUST_INSTALL_LIBSTD_TARGET)
>
> So, "install" doesn't actually install it, it just puts stuff in
> build/tmp/dist/... ? Isn't there a way to tell it to put stuff directly into
> HOST_DIR?
The `dist` command generates the install.sh scripts that are called by
the `install` command.
> > +endef
> > +
> > +$(eval $(host-generic-package))
> > diff --git a/package/rustc/Config.in.host b/package/rustc/Config.in.host
> > index 7f2c276..30bab8f 100644
> > --- a/package/rustc/Config.in.host
> > +++ b/package/rustc/Config.in.host
> > @@ -26,6 +26,20 @@ choice
> > help
> > Choose a provider for the Rust compiler.
> >
> > +config BR2_PACKAGE_HOST_RUST
> > + bool "host rust"
> > + depends on BR2_HOST_GCC_AT_LEAST_4_7 # required by LLVM
> > + # triggers ICE on trunc_int_for_mode, at explow.c:56
> > + depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 || !BR2_aarch64
> > + select BR2_PACKAGE_HAS_HOST_RUSTC
> > + help
> > + This package will build the compiler for the host as well as
> > + a cross-compiled version of the Rust standard library for the
> > + target.
> > +
> > +comment "host-rust needs a toolchain w/ gcc >= 5"
> > + depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_5 && BR2_aarch64
>
> Split in two lines:
>
> depends on BR2_aarch64
> depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_5
OK.
--
ELB
More information about the buildroot
mailing list