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

Delete the makefile build system #39431

Merged
merged 7 commits into from Feb 8, 2017
Merged

Conversation

@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Jan 31, 2017

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
Copy link
Collaborator

@rust-highfive rust-highfive commented Jan 31, 2017

r? @aturon

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

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jan 31, 2017

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned aturon Jan 31, 2017
@steveklabnik
Copy link
Member

@steveklabnik steveklabnik commented Jan 31, 2017

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
Copy link
Contributor

@petrochenkov petrochenkov commented Jan 31, 2017

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
Copy link
Contributor

@brson 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
Copy link
Contributor

@petrochenkov petrochenkov commented Feb 1, 2017

@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
Copy link
Member Author

@alexcrichton alexcrichton commented Feb 1, 2017

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
Copy link
Member Author

@alexcrichton alexcrichton commented Feb 1, 2017

@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
Copy link
Contributor

@ishitatsuyuki ishitatsuyuki commented Feb 2, 2017

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

Please make a list to track them.

@pnkfelix
Copy link
Member

@pnkfelix pnkfelix commented Feb 2, 2017

@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
Copy link
Member Author

@alexcrichton alexcrichton commented Feb 2, 2017

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

@brson
Copy link
Contributor

@brson brson commented Feb 2, 2017

@bors r+

@bors
Copy link
Contributor

@bors bors commented Feb 2, 2017

📌 Commit 39321aa has been approved by brson

@petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Feb 3, 2017

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

@ishitatsuyuki
Copy link
Contributor

@ishitatsuyuki ishitatsuyuki commented Feb 3, 2017

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
Copy link
Member Author

@alexcrichton alexcrichton commented Feb 3, 2017

@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
Copy link
Contributor

@ishitatsuyuki ishitatsuyuki commented Feb 3, 2017

@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
Copy link
Contributor

@ishitatsuyuki ishitatsuyuki commented Feb 3, 2017

Issue unblocked, I'm okay with the merge.

@bstrie
Copy link
Contributor

@bstrie 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
Copy link
Contributor

@bors bors commented Feb 4, 2017

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

@alexcrichton alexcrichton force-pushed the alexcrichton:no-more-makefiles branch from 39321aa to 2d51781 Feb 4, 2017
@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Feb 4, 2017

@bors: r=brson

@bors
Copy link
Contributor

@bors bors commented Feb 4, 2017

📌 Commit 2d51781 has been approved by brson

@@ -1,75 +0,0 @@
{

This comment has been minimized.

@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
Copy link
Contributor

@petrochenkov petrochenkov commented Feb 4, 2017

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

@bors
Copy link
Contributor

@bors bors commented Feb 4, 2017

🔒 Merge conflict

@steveklabnik steveklabnik mentioned this pull request Feb 6, 2017
9 of 10 tasks complete
@vi
Copy link
Contributor

@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 added a commit to frewsxcv/rust that referenced this pull request Feb 7, 2017
…rson

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!
bors added a commit that referenced this pull request Feb 7, 2017
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:
frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 7, 2017
…rson

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!
bors added a commit that referenced this pull request Feb 7, 2017
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:
@frewsxcv
Copy link
Member

@frewsxcv frewsxcv commented Feb 7, 2017

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

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Feb 7, 2017

@frewsxcv nah that's #38878

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 8, 2017
…rson

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!
bors added a commit that referenced this pull request Feb 8, 2017
bors added a commit that referenced this pull request Feb 8, 2017
frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 8, 2017
…rson

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!
bors added a commit that referenced this pull request Feb 8, 2017
Rollup of 13 pull requests

- Successful merges: #38764, #39361, #39372, #39374, #39400, #39426, #39431, #39459, #39482, #39545, #39593, #39620, #39621
- Failed merges:
@bors bors merged commit c8e0d04 into rust-lang:master Feb 8, 2017
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Nashenas88
Copy link
Contributor

@Nashenas88 Nashenas88 commented Feb 8, 2017

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

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Feb 8, 2017

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
Copy link

@J-F-Liu J-F-Liu commented Feb 10, 2017

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
Copy link
Member

@steveklabnik steveklabnik commented Feb 10, 2017

bors added a commit that referenced this pull request Feb 14, 2017
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
bors added a commit that referenced this pull request Feb 14, 2017
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
bors added a commit that referenced this pull request Feb 15, 2017
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
anatol pushed a commit to anatol/steed that referenced this pull request Mar 31, 2017
Port books to mdbook

Part of rust-lang/rust#39588

blocked on rust-lang/rust#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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

You can’t perform that action at this time.