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: Fix dist for non-host targets #32544

Merged
merged 1 commit into from
Apr 2, 2016

Conversation

alexcrichton
Copy link
Member

The rust-std package that we produce is expected to have not only the standard
library but also libtest for compiling unit tests. Unfortunately this does not
currently happen due to the way rustbuild is structured.

There are currently two main stages of compilation in rustbuild, one for the
standard library and one for the compiler. This is primarily done to allow us to
fill in the sysroot right after the standard library has finished compiling to
continue compiling the rest of the crates. Consequently the entire compiler does
not have to explicitly depend on the standard library, and this also should
allow us to pull in crates.io dependencies into the build in the future because
they'll just naturally build against the std we just produced.

These phases, however, do not represent a cross-compiled build. Target-only
builds also require libtest, and libtest is currently part of the
all-encompassing "compiler build". There's unfortunately no way to learn about
just libtest and its dependencies (in a great and robust fashion) so to ensure
that we can copy the right artifacts over this commit introduces a new build
step, libtest.

The new libtest build step has documentation, dist, and link steps as std/rustc
already do. The compiler now depends on libtest instead of libstd, and all
compiler crates can now assume that test and its dependencies are implicitly
part of the sysroot (hence explicit dependencies being removed). This makes the
build a tad less parallel as in theory many rustc crates can be compiled in
parallel with libtest, but this likely isn't where we really need parallelism
either (all the time is still spent in the compiler).

All in all this allows the dist-std step to depend on both libstd and libtest,
so rust-std packages produced by rustbuild should start having both the
standard library and libtest.

Closes #32523

@alexcrichton
Copy link
Member Author

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned nikomatsakis Mar 28, 2016
@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

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

@alexcrichton alexcrichton force-pushed the rustbuild-dist-libtest branch from df83dad to e9d6016 Compare March 28, 2016 23:20
@larsbergstrom
Copy link
Contributor

@brson if you have a second, could you please look at landing this? It's currently blocking Servo's already somewhat-delayed rust upgrade (see servo/servo#10173). Thanks!

@brson
Copy link
Contributor

brson commented Mar 30, 2016

@bors r+

@bors
Copy link
Contributor

bors commented Mar 30, 2016

📌 Commit e9d6016 has been approved by brson

@nox
Copy link
Contributor

nox commented Mar 31, 2016

So I guess this won't be in nightly 2016-03-31?

@bors
Copy link
Contributor

bors commented Apr 1, 2016

⌛ Testing commit e9d6016 with merge d69d5dc...

@bors
Copy link
Contributor

bors commented Apr 1, 2016

💔 Test failed - auto-win-gnu-32-opt-rustbuild

@retep998
Copy link
Member

retep998 commented Apr 1, 2016

3221225781C0000135STATUS_DLL_NOT_FOUND

@nox
Copy link
Contributor

nox commented Apr 1, 2016

Could we get this addressed? This is still blocking Servo.

@aturon
Copy link
Member

aturon commented Apr 1, 2016

@alexcrichton: feel free to jump the queue here.

The `rust-std` package that we produce is expected to have not only the standard
library but also libtest for compiling unit tests. Unfortunately this does not
currently happen due to the way rustbuild is structured.

There are currently two main stages of compilation in rustbuild, one for the
standard library and one for the compiler. This is primarily done to allow us to
fill in the sysroot right after the standard library has finished compiling to
continue compiling the rest of the crates. Consequently the entire compiler does
not have to explicitly depend on the standard library, and this also should
allow us to pull in crates.io dependencies into the build in the future because
they'll just naturally build against the std we just produced.

These phases, however, do not represent a cross-compiled build. Target-only
builds also require libtest, and libtest is currently part of the
all-encompassing "compiler build". There's unfortunately no way to learn about
just libtest and its dependencies (in a great and robust fashion) so to ensure
that we can copy the right artifacts over this commit introduces a new build
step, libtest.

The new libtest build step has documentation, dist, and link steps as std/rustc
already do. The compiler now depends on libtest instead of libstd, and all
compiler crates can now assume that test and its dependencies are implicitly
part of the sysroot (hence explicit dependencies being removed). This makes the
build a tad less parallel as in theory many rustc crates can be compiled in
parallel with libtest, but this likely isn't where we really need parallelism
either (all the time is still spent in the compiler).

All in all this allows the `dist-std` step to depend on both libstd and libtest,
so `rust-std` packages produced by rustbuild should start having both the
standard library and libtest.

Closes rust-lang#32523
@alexcrichton alexcrichton force-pushed the rustbuild-dist-libtest branch from e9d6016 to 3d6340f Compare April 1, 2016 17:18
@alexcrichton
Copy link
Member Author

@bors: r=brson 3d6340f p=1

@bors
Copy link
Contributor

bors commented Apr 1, 2016

⌛ Testing commit 3d6340f with merge c8b8eb1...

bors added a commit that referenced this pull request Apr 1, 2016
rustbuild: Fix dist for non-host targets

The `rust-std` package that we produce is expected to have not only the standard
library but also libtest for compiling unit tests. Unfortunately this does not
currently happen due to the way rustbuild is structured.

There are currently two main stages of compilation in rustbuild, one for the
standard library and one for the compiler. This is primarily done to allow us to
fill in the sysroot right after the standard library has finished compiling to
continue compiling the rest of the crates. Consequently the entire compiler does
not have to explicitly depend on the standard library, and this also should
allow us to pull in crates.io dependencies into the build in the future because
they'll just naturally build against the std we just produced.

These phases, however, do not represent a cross-compiled build. Target-only
builds also require libtest, and libtest is currently part of the
all-encompassing "compiler build". There's unfortunately no way to learn about
just libtest and its dependencies (in a great and robust fashion) so to ensure
that we can copy the right artifacts over this commit introduces a new build
step, libtest.

The new libtest build step has documentation, dist, and link steps as std/rustc
already do. The compiler now depends on libtest instead of libstd, and all
compiler crates can now assume that test and its dependencies are implicitly
part of the sysroot (hence explicit dependencies being removed). This makes the
build a tad less parallel as in theory many rustc crates can be compiled in
parallel with libtest, but this likely isn't where we really need parallelism
either (all the time is still spent in the compiler).

All in all this allows the `dist-std` step to depend on both libstd and libtest,
so `rust-std` packages produced by rustbuild should start having both the
standard library and libtest.

Closes #32523
@bors bors merged commit 3d6340f into rust-lang:master Apr 2, 2016
@alexcrichton alexcrichton deleted the rustbuild-dist-libtest branch May 2, 2016 18:45
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.

9 participants