Delete the makefile build system #39431

Merged
merged 7 commits into from Feb 8, 2017

Projects

None yet
@alexcrichton
Member

This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.

Rustbuild has been the default build system since 1.15.0 and the makefiles were proposed for deletion at this time back in November of last year.

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!

@rust-highfive
Collaborator

r? @aturon

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

@alexcrichton
Member

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned aturon Jan 31, 2017
@steveklabnik
Contributor
steveklabnik commented Jan 31, 2017 edited

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!

I know I already did a 🎊 reaction, but this deserves many more.

🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊

@petrochenkov
Contributor
petrochenkov commented Jan 31, 2017 edited

Please fix #36385 before removing the old build system, this is a blocker.

I planned to do it myself, but I won't be able to do it before this PR is merged.

@brson
Contributor
brson commented Feb 1, 2017

The patch looks fine to me.

@petrochenkov #36385 seems like both a difficult problem to solve and one that isn't causing a great deal of pain (Rust devs are still developing and nobody has fixed it). Should we really stop and tackle that right now?

@petrochenkov
Contributor

@brson
@alexcrichton already suggested a solution, is well familiar with the build and is a master of hacking up kinda working systems quickly.
My estimation for the simplest (but very helpful) solution with timestamps (one timestamp for a whole test group, aux files may be not considered at all) is a couple of hours.

Rust devs are still developing

That's because the old build systems still exists! Otherwise, they probably don't develop on Windows, or irresponsibly submit untested PRs.

@alexcrichton
Member

Let's just put that issue to rest, a commit's now attached to this PR. I was hoping to give someone else a chance to get their feet wet with the build system and/or compiletest, but oh well.

@alexcrichton
Member

@petrochenkov FWIW I've found the way you've approached #36385 as somewhat frustrating and unproductive. You've repeatedly brought it up and as you've notice I tried to outline clear solutions. There's been ample time (2 whole release cycles) where the deprecation of the makefiles has been announced, so this PR shouldn't come as a surprise.

In the future it'd be great to take a more proactive and less passive-aggressive stance towards solving these sorts of issues.

@ishitatsuyuki
Contributor

There's many critical issues breaking shared linking build, like #39215.

Please make a list to track them.

@pnkfelix
Member
pnkfelix commented Feb 2, 2017 edited

@alexcrichton

Let's just put that issue to rest, a commit's now attached to this PR. I was hoping to give someone else a chance to get their feet wet with the build system and/or compiletest, but oh well.

Wait, why isn't that commit a separate PR?

Surely that would be a step forward to let people concerned about the makefiles going away verify that they can use rustbuild before landing this whole PR too?


Update: I guess the idea was to ensure that this PR didn't land without ensuring that the test result caching didn't land as well? (Too bad github doesn't have a direct way to express such dependencies between PR's, as far as I know...)

@alexcrichton
Member

@pnkfelix well I don't really mind any particular organization, I'd just like to land this!

@brson
Contributor
brson commented Feb 2, 2017

@bors r+

@bors
Contributor
bors commented Feb 2, 2017

πŸ“Œ Commit 39321aa has been approved by brson

@petrochenkov
Contributor

@pnkfelix
I've cherry-picked 39321aa and tested it locally (report).

@ishitatsuyuki
Contributor
ishitatsuyuki commented Feb 3, 2017 edited

What are you guys doing?
Rust 1.15 came to stable this morning, you guys have already annoyed package maintainers by releasing a **** flawed buildsystem.

Please, delay the removal until the (dynamic) linking issues are fixed.

@alexcrichton
Member

@ishitatsuyuki as explained in the PR this is a long time coming. We've still got 3 months before this hits stable anyway to fix more issues as they arise.

Rewriting a build system is almost guaranteed to not be bug-for-bug compatible, so many quirks and bugs of the makefiles are not carried over (either accidentally or intentionally). Issues like #39215 were barely ever supported by the makefiles (if at all, only by luck) and aren't really a great reason to completely block this in my opinion.

These bug fixes tend to just be a line here or there, and PRs are always welcome!

@ishitatsuyuki
Contributor

@alexcrichton I'm concerned about breaking distro packaging entirely by only testing on rustup.

A buildsystem definitely should not be flawed (flawed by default is annoying enough though), and we will completely lose dynamic linking if you removed the old one.

Be patient. You didn't tend to break old rust code, but you're going to break up-to-date distro build script now. (By the way, this would also break the rust-git package in AUR)

@ishitatsuyuki
Contributor

Issue unblocked, I'm okay with the merge.

@bstrie
Contributor
bstrie commented Feb 3, 2017

As much as I'd love to forge ahead with Cargo, I agree with @ishitatsuyuki that we should make explicit overtures to Rust packagers to make sure they have everything they need to exist in a world without makefiles.

@bors
Contributor
bors commented Feb 4, 2017

β˜”οΈ The latest upstream changes (presumably #39463) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Member

@bors: r=brson

@bors
Contributor
bors commented Feb 4, 2017

πŸ“Œ Commit 2d51781 has been approved by brson

@@ -1,75 +0,0 @@
-{
@tamird
tamird Feb 4, 2017 Contributor

how come these files are no longer needed? where do valgrind suppressions come from these days? I grepped around and couldn't find it.

@petrochenkov
Contributor

@alexcrichton
The test caching commit has suddenly disappeared after rebase.

@bors
Contributor
bors commented Feb 4, 2017

πŸ”’ Merge conflict

@bors
Contributor
bors commented Feb 4, 2017

β˜”οΈ The latest upstream changes (presumably #39425) made this pull request unmergeable. Please resolve the merge conflicts.

@ishitatsuyuki
Contributor

Please also make sure that you have translated recent changes like #39425 into rustbuild.

@jakllsch
Contributor
jakllsch commented Feb 4, 2017

@ishitatsuyuki: #39425 contained changes for both rustbuild and the makefile system.

@alexcrichton
Member

@petrochenkov oops mixed up the branches

@ishitatsuyuki yes as you can see in the changes made in #39425, rustbuild is already changed.

@bors: r=brson

@bors
Contributor
bors commented Feb 4, 2017

πŸ“Œ Commit ca7886a has been approved by brson

@tamird
Contributor
tamird commented Feb 4, 2017

@alexcrichton can you help me understand why the valgrind suppressions are no longer needed?

@alexcrichton
Member

@tamird oh sorry I missed that. We haven't used those suppressions in ages and they're just ancient artifacts at this point. I'd be quite surprised if they're at all accurate/working any more

@alexcrichton
Member

@bors: r=brson

@bors
Contributor
bors commented Feb 4, 2017

πŸ“Œ Commit e80b17b has been approved by brson

@tamird
Contributor
tamird commented Feb 4, 2017
@frewsxcv frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 5, 2017
@frewsxcv frewsxcv Rollup merge of #39431 - alexcrichton:no-more-makefiles, r=brson
Delete the makefile build system

This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.

Rustbuild has been the default build system [since 1.15.0](rust-lang#37817) and the makefiles were [proposed for deletion](https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368) at this time back in November of last year.

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!
0631f0a
@bors bors added a commit that referenced this pull request Feb 5, 2017
@bors bors Auto merge of #39551 - frewsxcv:rollup, r=frewsxcv
Rollup of 14 pull requests

- Successful merges: #38518, #38921, #38959, #38983, #39009, #39107, #39431, #39443, #39453, #39454, #39471, #39477, #39478, #39527
- Failed merges:
6b43d7f
@frewsxcv
Member
frewsxcv commented Feb 5, 2017

This PR might have caused this issue during the rollup: https://travis-ci.org/rust-lang/rust/jobs/198487299

@frewsxcv
Member
frewsxcv commented Feb 5, 2017

@bors r- try

@bors
Contributor
bors commented Feb 5, 2017

βŒ›οΈ Trying commit e80b17b with merge fe703fb...

@bors bors added a commit that referenced this pull request Feb 5, 2017
@bors bors Auto merge of #39431 - alexcrichton:no-more-makefiles, r=<try>
Delete the makefile build system

This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.

Rustbuild has been the default build system [since 1.15.0](#37817) and the makefiles were [proposed for deletion](https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368) at this time back in November of last year.

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!
fe703fb
@frewsxcv
Member
frewsxcv commented Feb 5, 2017

It looks like running 'try' does not test all environments, so it's unlikely to reproduce the MIPS issue

@alexcrichton
Member

@bors: r=brson

FWIW I don't think try really works for us, although I have no idea why

@bors
Contributor
bors commented Feb 5, 2017

πŸ“Œ Commit 0a0a946 has been approved by brson

@badboy badboy referenced this pull request in bors-ng/bors-ng Feb 5, 2017
Closed

Add a comment when PR is approved #87

@vi
vi commented Feb 5, 2017 edited

Does this (crate.io-ifying rustc) mean boostrapping Rust from the ground up got harder or got easier?

@cuviper
Contributor
cuviper commented Feb 6, 2017

Before, you only needed cross-compiled rustc to natively bootstrap on a new platform. Now you'll need rust-std and cargo too.

@bors
Contributor
bors commented Feb 6, 2017

βŒ›οΈ Testing commit 0a0a946 with merge ebd9ef2...

@bors bors added a commit that referenced this pull request Feb 6, 2017
@bors bors Auto merge of #39431 - alexcrichton:no-more-makefiles, r=brson
Delete the makefile build system

This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.

Rustbuild has been the default build system [since 1.15.0](#37817) and the makefiles were [proposed for deletion](https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368) at this time back in November of last year.

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!
ebd9ef2
@bors
Contributor
bors commented Feb 6, 2017

πŸ’” Test failed - status-travis

@alexcrichton
Member

@bors: r=brson

@bors
Contributor
bors commented Feb 6, 2017

πŸ“Œ Commit 9a620c8 has been approved by brson

@vi
vi commented Feb 6, 2017

@cuviper , "from the ground up" means without using anything that is Rust-related pre-built. For example, while also doing security audit.

@bors
Contributor
bors commented Feb 6, 2017

βŒ›οΈ Testing commit 9a620c8 with merge 356d688...

@bors bors added a commit that referenced this pull request Feb 6, 2017
@bors bors Auto merge of #39431 - alexcrichton:no-more-makefiles, r=brson
Delete the makefile build system

This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.

Rustbuild has been the default build system [since 1.15.0](#37817) and the makefiles were [proposed for deletion](https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368) at this time back in November of last year.

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!
356d688
@bors
Contributor
bors commented Feb 6, 2017

πŸ’” Test failed - status-appveyor

src/etc/make-win-dist.py
@@ -1,124 +0,0 @@
-# Copyright 2013-2014 The Rust Project Developers. See the COPYRIGHT
@tamird
tamird Feb 6, 2017 Contributor

looks like this file is still needed

@aidanhs
Contributor
aidanhs commented Feb 6, 2017

Is there an issue somewhere for tracking feature parity between rustbuild and the makefiles or shall I raise one? I was curious so had a quick look over the weekend and noticed that --disable-stage0-landing-pads doesn't work (along with some others).

@alexcrichton
Member

@bors: r=brson

@tamird alas well we'll get rid of that file one day!

@aidanhs feel free to file issues! At this point we're in 'issue per bug' territory, not 'pile on tracking issue'

@bors
Contributor
bors commented Feb 6, 2017

πŸ“Œ Commit 861411a has been approved by brson

@tamird
Contributor
tamird commented Feb 6, 2017

@alexcrichton re-adding that file in the last commit means that its git history is obliterated. Perhaps you could avoid its removal altogether?

alexcrichton added some commits Jan 23, 2017
@alexcrichton alexcrichton Delete the `mk` folder
This commit deletes the old build system located in the `mk` folder as it's now
been obsoleted for two cycles and is replaced by rustbuild.
9ab8090
@alexcrichton alexcrichton Delete swaths of the configure script
This commit deletes swaths of the configure script related to the old build
system which are now no longer needed when using rustbuild.
9b0e6af
@alexcrichton alexcrichton Delete Travis/AppVeyor makefile builders
We no longer need these builders as we're no longer testing the old build
system.
ce4abc3
@alexcrichton alexcrichton std: Remove cfg(cargobuild) annotations
These are all now no longer needed that we've only got rustbuild in tree.
77c3bfa
@alexcrichton alexcrichton Clean our src/etc of old files
Some of these have long since expired, some are no longer in use now that we've
jettisoned the makefiles, but none of them should be needed any more.
ffd3070
@alexcrichton alexcrichton rustbuild: Fix a few locations with makefiles gone
* Add version info to channel.rs as main.mk is no longer available
* Update `Makefile.in` used with bootstrap to not try to require `mk/util.mk`
* Update the `dist` target to avoid the makefile pieces
9ad13c8
@alexcrichton alexcrichton compiletest: Add caching of test results
Don't re-run tests in compiletest if all the inputs haven't changed, manage
stamp files in the output directory.
c8e0d04
@alexcrichton
Member

@bors: r=brson

@bors
Contributor
bors commented Feb 6, 2017

πŸ“Œ Commit c8e0d04 has been approved by brson

@cuviper
Contributor
cuviper commented Feb 6, 2017

@vi, so you'd have to rebuild the entire chain from before it was self-hosting, written in OCaml? I guess the added challenge with rustbuild may be in locating historical crates.io packages, but note that those sources are vendored in the rust tree. You might also need that vendoring for cargo though. I suggest you start a thread on the internals forum if this is something you want to be able to do.

@steveklabnik steveklabnik referenced this pull request Feb 6, 2017
Open

Tracking issue for RFC 1828: Rust Bookshelf #39588

3 of 8 tasks complete
@vi
vi commented Feb 6, 2017

@cuviper, As far as I know there are projects for making Rust bootstrappable without repeating it's entire history from Ocaml across all intermediate releases. Like a simplified non-verifying non-optimizing Rust interpreter or compiler written in C.

@frewsxcv frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 7, 2017
@frewsxcv frewsxcv Rollup merge of #39431 - alexcrichton:no-more-makefiles, r=brson
Delete the makefile build system

This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.

Rustbuild has been the default build system [since 1.15.0](rust-lang#37817) and the makefiles were [proposed for deletion](https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368) at this time back in November of last year.

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!
3d9c01c
@bors bors added a commit that referenced this pull request Feb 7, 2017
@bors bors Auto merge of #39605 - frewsxcv:rollup, r=frewsxcv
Rollup of 18 pull requests

- Successful merges: #38764, #39361, #39400, #39426, #39431, #39482, #39512, #39523, #39557, #39561, #39582, #39583, #39586, #39587, #39598, #39599, #39601, #39604
- Failed merges:
f983c3c
@frewsxcv frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 7, 2017
@frewsxcv frewsxcv Rollup merge of #39431 - alexcrichton:no-more-makefiles, r=brson
Delete the makefile build system

This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.

Rustbuild has been the default build system [since 1.15.0](rust-lang#37817) and the makefiles were [proposed for deletion](https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368) at this time back in November of last year.

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!
3a11491
@bors bors added a commit that referenced this pull request Feb 7, 2017
@bors bors Auto merge of #39609 - frewsxcv:rollup, r=frewsxcv
Rollup of 18 pull requests

- Successful merges: #38764, #39361, #39400, #39426, #39431, #39482, #39523, #39557, #39561, #39582, #39583, #39586, #39587, #39598, #39599, #39601, #39602, #39604
- Failed merges:
6a0c19f
@frewsxcv
Member
frewsxcv commented Feb 7, 2017

@alexcrichton Does this fail from my rollup seem relevant to your changes here?

@alexcrichton
Member

@frewsxcv nah that's #38878

@frewsxcv frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 8, 2017
@frewsxcv frewsxcv Rollup merge of #39431 - alexcrichton:no-more-makefiles, r=brson
Delete the makefile build system

This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.

Rustbuild has been the default build system [since 1.15.0](rust-lang#37817) and the makefiles were [proposed for deletion](https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368) at this time back in November of last year.

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!
caf3bc5
This was referenced Feb 8, 2017
@frewsxcv frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 8, 2017
@frewsxcv frewsxcv Rollup merge of #39431 - alexcrichton:no-more-makefiles, r=brson
Delete the makefile build system

This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.

Rustbuild has been the default build system [since 1.15.0](rust-lang#37817) and the makefiles were [proposed for deletion](https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368) at this time back in November of last year.

And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!
6fb57bf
@bors bors added a commit that referenced this pull request Feb 8, 2017
@bors bors Auto merge of #39638 - frewsxcv:rollup, r=frewsxcv
Rollup of 13 pull requests

- Successful merges: #38764, #39361, #39372, #39374, #39400, #39426, #39431, #39459, #39482, #39545, #39593, #39620, #39621
- Failed merges:
10f6a5c
@bors bors merged commit c8e0d04 into rust-lang:master Feb 8, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Nashenas88
Contributor

Shouldn't the main README.md also be updated? It still says to use make.

@alexcrichton
Member

Nah we still have a bare-bones makefile at least for familiarity, so that documentation is still correct. We may wish to feature x.py more prominently though!

@alexcrichton alexcrichton deleted the alexcrichton:no-more-makefiles branch Feb 8, 2017
@J-F-Liu
J-F-Liu commented Feb 10, 2017 edited

It will also be good to split current compiler into several crates, e.g. lexer, parser, hir, mir etc. This is a win-win situation.

  • The compiler components can be reused in other projects.
  • Crates can compete with each other which results in a better compiler.
@steveklabnik
Contributor
@bors bors added a commit that referenced this pull request Feb 14, 2017
@bors bors Auto merge of #39633 - steveklabnik:vendor-mdbook, r=alexcrichton
Port books to mdbook

Part of #39588

blocked on #39431

As a first step towards the bookshelf, we ~vendor mdbook in-tree and~ port our books to it. Eventually, both of these books will be moved out-of-tree, but the nightly book will rely on doing the same thing. As such, this intermediate step is useful.

r? @alexcrichton @brson

/cc @azerupi
f19eb11
@bors bors added a commit that referenced this pull request Feb 14, 2017
@bors bors Auto merge of #39633 - steveklabnik:vendor-mdbook, r=alexcrichton
Port books to mdbook

Part of #39588

blocked on #39431

As a first step towards the bookshelf, we ~vendor mdbook in-tree and~ port our books to it. Eventually, both of these books will be moved out-of-tree, but the nightly book will rely on doing the same thing. As such, this intermediate step is useful.

r? @alexcrichton @brson

/cc @azerupi
c3ab706
@bors bors added a commit that referenced this pull request Feb 15, 2017
@bors bors Auto merge of #39633 - steveklabnik:vendor-mdbook, r=alexcrichton
Port books to mdbook

Part of #39588

blocked on #39431

As a first step towards the bookshelf, we ~vendor mdbook in-tree and~ port our books to it. Eventually, both of these books will be moved out-of-tree, but the nightly book will rely on doing the same thing. As such, this intermediate step is useful.

r? @alexcrichton @brson

/cc @azerupi
025c328
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment