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

Conversation

Projects
None yet
@alexcrichton
Member

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

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Jan 31, 2017

Collaborator

r? @aturon

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

Collaborator

rust-highfive commented Jan 31, 2017

r? @aturon

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton
Member

alexcrichton commented Jan 31, 2017

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned aturon Jan 31, 2017

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Jan 31, 2017

Member

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.

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Jan 31, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Feb 1, 2017

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Feb 1, 2017

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 1, 2017

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 1, 2017

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@ishitatsuyuki

ishitatsuyuki Feb 2, 2017

Member

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

Please make a list to track them.

Member

ishitatsuyuki commented Feb 2, 2017

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

Please make a list to track them.

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Feb 2, 2017

Member

@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...)

Member

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 2, 2017

Member

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

Member

alexcrichton commented Feb 2, 2017

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

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Feb 2, 2017

Contributor

@bors r+

Contributor

brson commented Feb 2, 2017

@bors r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Feb 2, 2017

Contributor

📌 Commit 39321aa has been approved by brson

Contributor

bors commented Feb 2, 2017

📌 Commit 39321aa has been approved by brson

@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Feb 3, 2017

Contributor

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

Contributor

petrochenkov commented Feb 3, 2017

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

@ishitatsuyuki

This comment has been minimized.

Show comment
Hide comment
@ishitatsuyuki

ishitatsuyuki Feb 3, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 3, 2017

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!

Member

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

This comment has been minimized.

Show comment
Hide comment
@ishitatsuyuki

ishitatsuyuki Feb 3, 2017

Member

@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)

Member

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

This comment has been minimized.

Show comment
Hide comment
@ishitatsuyuki

ishitatsuyuki Feb 3, 2017

Member

Issue unblocked, I'm okay with the merge.

Member

ishitatsuyuki commented Feb 3, 2017

Issue unblocked, I'm okay with the merge.

@bstrie

This comment has been minimized.

Show comment
Hide comment
@bstrie

bstrie Feb 3, 2017

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@bors

bors Feb 4, 2017

Contributor

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

Contributor

bors commented Feb 4, 2017

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 4, 2017

Member

@bors: r=brson

Member

alexcrichton commented Feb 4, 2017

@bors: r=brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Feb 4, 2017

Contributor

📌 Commit 2d51781 has been approved by brson

Contributor

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.

@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

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Feb 4, 2017

Contributor

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

Contributor

petrochenkov commented Feb 4, 2017

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

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Feb 4, 2017

Contributor

🔒 Merge conflict

Contributor

bors commented Feb 4, 2017

🔒 Merge conflict

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Feb 4, 2017

Contributor

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

Contributor

bors commented Feb 4, 2017

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

@steveklabnik steveklabnik referenced this pull request Feb 6, 2017

Closed

Tracking issue for RFC 1828: Rust Bookshelf #39588

9 of 10 tasks complete
@vi

This comment has been minimized.

Show comment
Hide comment
@vi

vi Feb 6, 2017

Contributor

@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.

Contributor

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

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!

bors added a commit that referenced this pull request Feb 7, 2017

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:

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 7, 2017

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!

bors added a commit that referenced this pull request Feb 7, 2017

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:
@frewsxcv

This comment has been minimized.

Show comment
Hide comment
@frewsxcv

frewsxcv Feb 7, 2017

Member

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

Member

frewsxcv commented Feb 7, 2017

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton
Member

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

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!

@steveklabnik steveklabnik referenced this pull request Feb 8, 2017

Merged

Port books to mdbook #39633

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

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!

bors added a commit that referenced this pull request Feb 8, 2017

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:

@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

This comment has been minimized.

Show comment
Hide comment
@Nashenas88

Nashenas88 Feb 8, 2017

Contributor

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

Contributor

Nashenas88 commented Feb 8, 2017

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 8, 2017

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!

Member

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

This comment has been minimized.

Show comment
Hide comment
@J-F-Liu

J-F-Liu 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.

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

This comment has been minimized.

Show comment
Hide comment
@steveklabnik
Member

steveklabnik commented Feb 10, 2017

bors added a commit that referenced this pull request Feb 14, 2017

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

bors added a commit that referenced this pull request Feb 14, 2017

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

bors added a commit that referenced this pull request Feb 15, 2017

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

anatol pushed a commit to anatol/steed that referenced this pull request Mar 31, 2017

Auto merge of #39633 - steveklabnik:vendor-mdbook, r=alexcrichton
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