Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ebuild changes to use rustbuild and multiple targets #244

Open
sezaru opened this issue Mar 14, 2017 · 5 comments
Open

Ebuild changes to use rustbuild and multiple targets #244

sezaru opened this issue Mar 14, 2017 · 5 comments

Comments

@sezaru
Copy link

sezaru commented Mar 14, 2017

I've made some changes to the rust ebuild to support the newer and recommended rustbuild to build it, also, it is possible now to set more targets for the rustlibs (libcore, libstd, etc), so for example, if you have a toolchain for i686-unknown-linux-gnu, you can tell the ebuild to also build rustlibs using that toolchain compiler and install it with the package (so commands like cargo build --target i686-unknown-linux-gnu will simply work now).

This means that we can have a more powerful version of rustup inside portage domain.

Now, does these changes interest you? I can post then here if so, so we can discuss then better.

Also, one problem that I'm not sure how to solve is the way to tell portage what targets to build when emerging it, for now, just for test, I have it hard-coded to compile for x86_64-unknown-linux-gnu and i686-unknown-linux-gnu, should I create a use target flag for each target, like LLVM ebuild does? Or should the ebuild automatically find all crossdev toolchains installed in the machine and generate the targets for then all?

Thanks

@cnd
Copy link
Contributor

cnd commented Mar 14, 2017

sounds interesting
I didn't checked llvm ebuild but I think it will be reasonable to support same targets specially when system llvm will be used (if that is still possible with that setup?)

@sezaru
Copy link
Author

sezaru commented Mar 16, 2017

Actually, at least the way I'm doing it, LLVM is not used for generating the targets, the toolchains compilers are.

For example, the i686-unknown-linux-gnu toolchain will have a i686-unknown-linux-gnu-gcc, this is the compiler that rust will use to generate it's rustlibs.

So a direct map from LLVM targets probably is not the best approach since it will not have all the possible alternatives.

I'm posting here the main changes I did to the ebuild so it will make the process more clear:

First I added new packages to be downloaded on SRC_URI:

SRC_URI="https://static.rust-lang.org/dist/${SRC} -> rustc-${PV}-src.tar.gz
         amd64? ( https://static.rust-lang.org/dist/${RUST_STAGE0_amd64}.tar.gz
                  https://static.rust-lang.org/dist/${STD_STAGE0_amd64}.tar.gz
                  https://s3.amazonaws.com/rust-lang-ci/cargo-builds/${CARGO_REVISION}/${CARGO_STAGE0_amd64}.tar.gz )
         x86? ( https://static.rust-lang.org/dist/${RUST_STAGE0_x86}.tar.gz
                https://static.rust-lang.org/dist/${STD_STAGE0_x86}.tar.gz
                https://s3.amazonaws.com/rust-lang-ci/cargo-builds/${CARGO_REVISION}/${CARGO_STAGE0_x86}.tar.gz )"

As you can see, now we download stage0 cargo and rustlibs since they are needed for rustbuild and we don't want rustbuild to download then during compilation.

During src_prepare() I extract everything and apply some patches that are needed to fix multiple targets and support for DESTDIR, the first is a fix that I'm doing a PR on rust repository for the next version of rust, and the second is a already applied fix that didn't made in rust 1.15.

More important stuff is on src_configure(), there I first create a file config.toml that rustbuild uses to configure multiple aspects when configuring the project that are not available on ./configure command, for now, I have this hard coded:

echo -e "[target.i686-unknown-linux-gnu]\n" \
        "cc = \"i686-unknown-linux-gnu-gcc\"\n" \
        "cxx = \"i686-unknown-linux-gnu-g++\"" > config.toml

As you can see, the above line will create the config.toml file with information on what compiler to use when the target is i686-unknown-linux-gnu. This, of course, needs to be generalized, so it will populate it with the targets selected from portage instead of hard coded like now.

After that, the next step is ./configure command:

"${ECONF_SOURCE:-.}"/configure \
	--prefix="${EPREFIX}/usr" \
	--libdir="${EPREFIX}/usr/$(get_libdir)" \
	--mandir="${EPREFIX}/usr/share/${P}/man" \
	--release-channel=${SLOT%%/*} \
	--disable-manage-submodules \
	--default-linker=$(tc-getBUILD_CC) \
	--default-ar=$(tc-getBUILD_AR) \
	--python=${EPYTHON} \
	--disable-rpath \
	--enable-local-rust \
	--local-rust-root="${WORKDIR}/stage0" \
	--target=x86_64-unknown-linux-gnu,i686-unknown-linux-gnu \
	$(use_enable clang) \
	$(use_enable debug) \
	$(use_enable debug llvm-assertions) \
	$(use_enable !debug optimize) \
	$(use_enable !debug optimize-cxx) \
	$(use_enable !debug optimize-llvm) \
	$(use_enable !debug optimize-tests) \
	$(use_enable doc docs) \
	$(use_enable libcxx libcpp) \
	$(usex system-llvm "--llvm-root=${EPREFIX}/usr" " ") \
	$(usex system-llvm "--enable-llvm-link-shared" " ") \
    || die

First I removed --disable-rustbuild for obvious reasons, then, important parts are --local-rust-root="${WORKDIR}/stage0" which tells the rustbuild where to find the stage0 files (the ones extracted in src_prepare() step) and --target=x86_64-unknown-linux-gnu,i686-unknown-linux-gnu which tells rustbuild what are the targets that will have rustlibs compiled, in this case, it is hard coded too with the host target (x86_64-unknown-linux-gnu) and my crossdev toolchain i686-unknown-linux-gnu.

There are other changes, but these are the main ones. If you want I can do a PR with the full ebuild already.

Maybe the best approach for the targets would be to have something like RUSTLIB_TARGETS in the ebuild which will have all targets from tier 1 and 2 (maybe 3 too?) from Rust Platform Support so someone could do this:

RUSTLIB_TARGETS="i686-unknown-linux-gnu arm-unknown-linux-gnueabi" emerge -1

Generating rustlibs for x86_64-unknown-linux-gnu (host), i686-unknown-linux-gnu and arm-unknown-linux-gnueabi. What do you think?

This obviously would need i686-unknown-linux-gnu-gcc and arm-unknown-linux-gnueabi-gcc to be on system PATH, this can be checked on src_prepare() step maybe.

@cnd
Copy link
Contributor

cnd commented Mar 19, 2017

@cardoe what do you think?

@cardoe
Copy link
Contributor

cardoe commented Mar 29, 2017

I'll have a peek

@crawford
Copy link

Has there been any progress on this? I'm interested in support for multiple targets (specifically, x86_64 and aarch64).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants