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

rustbuild: Implement make dist #32237

Merged
merged 1 commit into from
Mar 17, 2016
Merged

Conversation

alexcrichton
Copy link
Member

This commit implements the make dist command in the new rustbuild build
system, porting over dist.mk and prepare.mk into Rust. There's a huge amount
of complexity between those two files, not all of which is likely justified, so
the Rust implementation is much smaller.

Currently the implementation still shells out to rust-installer as well as some
python scripts, but ideally we'd rewrite it all in the future to not shell out
and be in Rust proper.

@rust-highfive
Copy link
Collaborator

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned aturon Mar 13, 2016
// installed
t!(fs::create_dir_all(&overlay));
let cp = |file: &str| {
t!(fs::copy(build.src.join(file), overlay.join(file)));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the install script uses the install command all over the place instead of just normal file copies. I'm... not really sure why, but maybe you know @brson? Was it to just explicitly control the permissions? I wouldn't mind adding a little wrapper to this module to do that, but I'm mainly just curious if there are reasons beyond permissions that install is used.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alexcrichton Just permissions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I think this code should change to set the permissions. The installer will actually set them all itself itself during install, but that's a hack because we've historically produced seemingly-broken tarballs that don't retain their permissions. The installer should not be doing that and the permissions should be configured correctly before packaging. Here's the permissions rust-installer expects.

@alexcrichton
Copy link
Member Author

For now this is also rebased on #32206, but the only relevant commit to this PR is the last one.

@alexcrichton alexcrichton force-pushed the rustbuild-make-dist branch 5 times, most recently from 2a01d58 to c00fef1 Compare March 14, 2016 05:10
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Mar 14, 2016
This commit fixes our support for cross compiling a compiler to run on FreeBSD.
Over the weekend I managed to get a cross compiler from Linux to FreeBSD [1]
which I hope to soon use to start producing FreeBSD nightly compilers. With the
`make dist` support added in rust-lang#32237 we should be able to produce standard
rustc/rust-std packages for FreeBSD through a new slave with this cross compiler.

Currently, however, we don't "Just Work" when cross compiling FreeBSD and a
number of changes were required (part of this PR). They include:

* A few build fixes were needed in LLVM. Our own branch has been rebased on the
  actual 3.8 release and I applied one extra commit [2] which contains two fixes:

  1. The LLVM CMake build system passes the `-Wl,-z,defs` flag on many
     platforms, but *not* when `CMAKE_SYSTEM_NAME` is "FreeBSD". Unfortunately
     this doesn't take into account when we're cross compiling, and as predicted
     the build will fail if `-Wl,-z,defs` is passed (see [3] for more info). To
     fix this we test `TARGET_TRIPLE` instead of the `CMAKE_SYSTEM_NAME` which
     is what we're compiling for which fixes the problem.
  2. The `PATH_MAX` constant is apparently defined in a different location than
     many other Unix systems, so a file which required this just needed some
     help to keep compiling.

* Support for compiling compiler-rt with CMake has been added to rustbuild. It
  looks like it just emulates Linux in what it compiles as it didn't seem to
  naturally produce anything else... At least the architecture is right, so
  seems good for now at least!

[1]: https://github.com/alexcrichton/port-of-rust/blob/master/prebuilt/freebsd/Dockerfile
[2]: rust-lang/llvm@be89e4b5
[3]: https://bugs.webkit.org/show_bug.cgi?id=138420
@bors
Copy link
Contributor

bors commented Mar 15, 2016

☔ The latest upstream changes (presumably #32206) made this pull request unmergeable. Please resolve the merge conflicts.

bors added a commit that referenced this pull request Mar 15, 2016
rustbuild: Fix cross compiling to FreeBSD

This commit fixes our support for cross compiling a compiler to run on FreeBSD.
Over the weekend I managed to get a cross compiler from Linux to FreeBSD [1]
which I hope to soon use to start producing FreeBSD nightly compilers. With the
`make dist` support added in #32237 we should be able to produce standard
rustc/rust-std packages for FreeBSD through a new slave with this cross compiler.

Currently, however, we don't "Just Work" when cross compiling FreeBSD and a
number of changes were required (part of this PR). They include:

* A few build fixes were needed in LLVM. Our own branch has been rebased on the
  actual 3.8 release and I applied one extra commit [2] which contains two fixes:

  1. The LLVM CMake build system passes the `-Wl,-z,defs` flag on many
     platforms, but *not* when `CMAKE_SYSTEM_NAME` is "FreeBSD". Unfortunately
     this doesn't take into account when we're cross compiling, and as predicted
     the build will fail if `-Wl,-z,defs` is passed (see [3] for more info). To
     fix this we test `TARGET_TRIPLE` instead of the `CMAKE_SYSTEM_NAME` which
     is what we're compiling for which fixes the problem.
  2. The `PATH_MAX` constant is apparently defined in a different location than
     many other Unix systems, so a file which required this just needed some
     help to keep compiling.

* Support for compiling compiler-rt with CMake has been added to rustbuild. It
  looks like it just emulates Linux in what it compiles as it didn't seem to
  naturally produce anything else... At least the architecture is right, so
  seems good for now at least!

[1]: https://github.com/alexcrichton/port-of-rust/blob/master/prebuilt/freebsd/Dockerfile
[2]: rust-lang/llvm@be89e4b5
[3]: https://bugs.webkit.org/show_bug.cgi?id=138420
@japaric
Copy link
Member

japaric commented Mar 16, 2016

I tried configure --enable-rustbuild --host=arm-unknown-linux-gnueabihf --enable-dist-host-only && make && make dist with this PR and rustbuild generated these tarballs:

rust-docs-1.9.0-dev.tar.gz
rust-std-1.9.0-dev-arm-unknown-linux-gnueabihf.tar.gz
rust-std-1.9.0-dev-x86_64-unknown-linux-gnu.tar.gz
rustc-1.9.0-dev-x86_64-unknown-linux-gnu.tar.gz

Note that rustc-arm is missing. @alexcrichton suggested running python bootstrap.py --stage 2 --step dist --host arm-unknown-linux-gnueabihf to generate the missing tarball and I got this error:

$ python ../rust/src/bootstrap/bootstrap.py --stage 2 --step dist --host arm-unknown-linux-gnueabihf
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> arm-unknown-linux-gnueabihf)
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> arm-unknown-linux-gnueabihf)
Building stage2 std artifacts (arm-unknown-linux-gnueabihf -> arm-unknown-linux-gnueabihf)
failed to run `rustc` to learn about target-specific information

To learn more, run the command again with --verbose.


command did not execute successfully: "/buildslave/build/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "-j" "8" "--target" "arm-unknown-linux-gnueabihf" "--release" "--features" " jemalloc" "--manifest-path" "/buildslave/rust/src/rustc/std_shim/Cargo.toml"
expected success, got: exit code: 101

Which seems to indicate that rustbuild is trying to run the rustc ARM binary.

Then @alexcrichton suggested this patch. I applied and after calling make && make dist I got:

(...)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> arm-unknown-linux-gnueabihf)
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> arm-unknown-linux-gnueabihf)
Building stage2 std artifacts (arm-unknown-linux-gnueabihf -> arm-unknown-linux-gnueabihf)
failed to run `rustc` to learn about target-specific information

To learn more, run the command again with --verbose.


command did not execute successfully: "/buildslave/build/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "-j" "8" "--target" "arm-unknown-linux-gnueabihf" "--release" "--features" " jemalloc" "--manifest-path" "/buildslave/rust/src/rustc/std_shim/Cargo.toml"
expected success, got: exit code: 101

I hope this info helps to debug the problem!

@alexcrichton
Copy link
Member Author

Ok, I've pushed a commit which I believe fixes that problem. I... am not entirely sure how it fixes it but it seems to work locally.

@alexcrichton
Copy link
Member Author

Confirmed to work:

$ ./configure --host=i686-unknown-linux-gnu,arm-unknown-linux-gnueabihf --enable-rustbuild
$ make dist
[..]
$ ls build/dist
rustc-1.9.0-dev-arm-unknown-linux-gnueabihf.tar.gz      
rustc-1.9.0-dev-i686-unknown-linux-gnu.tar.gz           
rustc-1.9.0-dev-x86_64-unknown-linux-gnu.tar.gz         
rust-docs-1.9.0-dev.tar.gz                              
rust-std-1.9.0-dev-arm-unknown-linux-gnueabihf.tar.gz   
rust-std-1.9.0-dev-i686-unknown-linux-gnu.tar.gz        
rust-std-1.9.0-dev-x86_64-unknown-linux-gnu.tar.gz      

r? @brson

@brson
Copy link
Contributor

brson commented Mar 16, 2016

rust-buildbot expects that as part of dist the docs will be copied to dist/doc/$CFG_PACKAGE_VERS. This is where the docs are uploaded from, and also critically how rust-buildbot figures out the name of the package being built!

cp("LICENSE-MIT");
cp("README.md");
// tiny morsel of metadata is used by rust-packaging
let version = &build.version;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this value is incorrect. It should be something like rustc 1.9.0-nightly (c66d2380a 2016-03-15), exactly what rustc prints for --version.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh looks like I actually managed to accomodate for this!

This commit implements the `make dist` command in the new rustbuild build
system, porting over `dist.mk` and `prepare.mk` into Rust. There's a huge amount
of complexity between those two files, not all of which is likely justified, so
the Rust implementation is *much* smaller.

Currently the implementation still shells out to rust-installer as well as some
python scripts, but ideally we'd rewrite it all in the future to not shell out
and be in Rust proper.
@alexcrichton
Copy link
Member Author

re-r? @brson

Added an install function which sets permissions and also added the doc directory to make dist.

@brson
Copy link
Contributor

brson commented Mar 17, 2016

@bors r+

@bors
Copy link
Contributor

bors commented Mar 17, 2016

📌 Commit 6cc06b3 has been approved by brson

@bors
Copy link
Contributor

bors commented Mar 17, 2016

⌛ Testing commit 6cc06b3 with merge 0d746bc...

bors added a commit that referenced this pull request Mar 17, 2016
rustbuild: Implement `make dist`

This commit implements the `make dist` command in the new rustbuild build
system, porting over `dist.mk` and `prepare.mk` into Rust. There's a huge amount
of complexity between those two files, not all of which is likely justified, so
the Rust implementation is *much* smaller.

Currently the implementation still shells out to rust-installer as well as some
python scripts, but ideally we'd rewrite it all in the future to not shell out
and be in Rust proper.
@bors
Copy link
Contributor

bors commented Mar 17, 2016

💔 Test failed - auto-win-gnu-64-nopt-t

@alexcrichton
Copy link
Member Author

@bors: retry

On Wed, Mar 16, 2016 at 7:44 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-gnu-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-win-gnu-64-nopt-t/builds/3459


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#32237 (comment)

@bors
Copy link
Contributor

bors commented Mar 17, 2016

⌛ Testing commit 6cc06b3 with merge abb1515...

bors added a commit that referenced this pull request Mar 17, 2016
rustbuild: Implement `make dist`

This commit implements the `make dist` command in the new rustbuild build
system, porting over `dist.mk` and `prepare.mk` into Rust. There's a huge amount
of complexity between those two files, not all of which is likely justified, so
the Rust implementation is *much* smaller.

Currently the implementation still shells out to rust-installer as well as some
python scripts, but ideally we'd rewrite it all in the future to not shell out
and be in Rust proper.
@bors bors merged commit 6cc06b3 into rust-lang:master Mar 17, 2016
@alexcrichton alexcrichton deleted the rustbuild-make-dist branch March 27, 2016 17:49
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

Successfully merging this pull request may close these issues.

None yet

6 participants