Assume `build.rs` in the same directory as `Cargo.toml` is a build script (unless explicitly told not to) #3361

Merged
merged 5 commits into from Dec 7, 2016

Projects

None yet

6 participants

@pwoolcoc
Contributor
pwoolcoc commented Dec 2, 2016

So, in May I posted a question in the #cargo IRC room: https://botbot.me/mozilla/cargo/2016-05-26/?msg=66770068&page=1

This PR does what was discussed there. If cargo sees a build.rs in the same directory as the Cargo.toml, it will assume build.rs is a build script unless package.build = false. Just for completeness I also made build = true mean the same as build = "build.rs" but I'm not sure if that is okay or not.

@brson brson was assigned by rust-highfive Dec 2, 2016
@rust-highfive

r? @brson

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

pwoolcoc added some commits Dec 2, 2016
@pwoolcoc pwoolcoc Assume build = 'build.rs' by default
This change makes cargo assume `build = "build.rs"` if there is a
`build.rs` file in the same directory as `Cargo.toml`. However, you
can set `build = false` to prevent this.
ea2c6e8
@pwoolcoc pwoolcoc Tests for new `package.build` behavior
73e0244
@steveklabnik
Contributor

yessssssss i asked @alexcrichton about this a while back and he was 👍 at the time. I think this is great.

src/cargo/util/toml.rs
@@ -540,7 +546,11 @@ impl TomlManifest {
}
// processing the custom build script
- let new_build = project.build.as_ref().map(PathBuf::from);
+ let manifest_file = util::important_paths::find_root_manifest_for_wd(None, &layout.root)
@pwoolcoc
pwoolcoc Dec 2, 2016 Contributor

Looking this over again, I'm wondering if I actually have to do this, or if I can just assume base_dir == layout.root?

@pwoolcoc
Contributor
pwoolcoc commented Dec 2, 2016

@steveklabnik :) everyone who commented in #cargo seemed to support it, but it was a while ago, so I'm hoping the support is still there.

@alexcrichton
Member

Thanks for the PR! The implementation looks great to me as well.

My only hesitation here is that we risk breaking projects when this lands. Projects can fix builds with build = false in Cargo.toml, but I think that'll end up getting rejected on the stable/beta channels. In that sense, if a crate has a build.rs but it's not a build script, then you can't keep that layout and continue to work on stable/beta/nightly.

I'd also want to think through the backcompat story here with all crates published on crates.io. It may be worth doing a survey there to see how many crates have a build.rs file which isn't a build script, if any. If that number is 0, then our lives are much easier! If that number is greater, we may want to proactively reach out to authors to head off the breakage.

@pwoolcoc would you be willing to scrape crates.io and test for build.rs scripts in roots which aren't build scripts?

@pwoolcoc
Contributor
pwoolcoc commented Dec 3, 2016

@alexcrichton sure, I can do that.

Would it preferable to change it slightly to only print a deprecation warning when there is a build.rs that isn't a build script, and land the rest of the change after a couple releases?

@steveklabnik
Contributor
@pwoolcoc
Contributor
pwoolcoc commented Dec 3, 2016

@steveklabnik yea, if someone has a crate with a build.rs file in the same directory as Cargo.toml, and the build.rs is not a build script, then this patch will try to treat it as a build script. The user would have to add build = false to the package section of their Cargo.toml in order to prevent this.

@alexcrichton
Member

@pwoolcoc

Would it preferable to change it slightly to only print a deprecation warning when there is a build.rs that isn't a build script, and land the rest of the change after a couple releases?

If we have no existing build.rs scripts that aren't build scripts, I think we can avoid this. Otherwise yeah I think we'll need to take this route. I figure we should just get a handle on the situation first so we can categorize our options.

@steveklabnik

the way in which this would break is if someone had specially configured a build.rs at the top level to be source, correct?

Indeed! I agree that it should be rare if ever, but I just want to make sure!

pwoolcoc added some commits Dec 5, 2016
@pwoolcoc pwoolcoc Using layout.root here should be sufficient
e409049
@pwoolcoc pwoolcoc correct typo
d998dba
@pwoolcoc
Contributor
pwoolcoc commented Dec 5, 2016 edited

@alexcrichton ok, I'm finishing up the few crates that my script couldn't automatically check, but here are the preliminary results. There are 12 crates that have a build.rs in the same directory as a Cargo.toml, without an accompanying build = "build.rs" in the Cargo.toml file. However, all of the build.rs are build scripts that are just not being used. None of them are actually source code for the project. However, this still means that their builds might break from this change.

The 12 crates are:

@alexcrichton
Member

@pwoolcoc thanks for the investigation! Looking at those thought I think that this change would break most of those crates unfortunately. Most of the build scripts have an extern crate directive which isn't listed in [build-dependencies].

Given that we may need to pursue a strategy like:

  • Add knowledge of build = <bool>
  • If build isn't specified and build.rs exists, generate a warning

We probably need to let that bake for quite some time, and then after that's in we can enable the auto-detection. What do you think?

@pwoolcoc
Contributor
pwoolcoc commented Dec 6, 2016 edited

@alexcrichton sounds good, I suspected as much, so I have a patch ready to go for this. So to be clear, the new behavior would be:

  1. If build = "build.rs" is present, same behavior as today
  2. if build = true is present, it is equivalent to build = "build.rs", regardless of the existence of build.rs
  3. If build = false is present, it is equivalent to not having a build value at all, regardless of the existence of build.rs
  4. If build = ... is not present, and a build.rs file is present, a warning would be printed.

Does that sound right? I'll push my last commit so you can look it over, too.

@alexcrichton
Member

@pwoolcoc sounds exactly right to me!

@pwoolcoc pwoolcoc change this to only emit a warning right now
1b99491
@pwoolcoc
Contributor
pwoolcoc commented Dec 6, 2016
@rust-highfive rust-highfive assigned alexcrichton and unassigned brson Dec 6, 2016
@alexcrichton
Member

@bors: r+

Thanks!

@bors
Contributor
bors commented Dec 7, 2016

📌 Commit 1b99491 has been approved by alexcrichton

@bors
Contributor
bors commented Dec 7, 2016

⌛️ Testing commit 1b99491 with merge 333a798...

@bors bors added a commit that referenced this pull request Dec 7, 2016
@bors bors Auto merge of #3361 - pwoolcoc:default-build-script, r=alexcrichton
Assume `build.rs` in the same directory as `Cargo.toml` is a build script (unless explicitly told not to)

So, in May I posted a question in the #cargo IRC room: https://botbot.me/mozilla/cargo/2016-05-26/?msg=66770068&page=1

This PR does what was discussed there. If `cargo` sees a `build.rs` in the same directory as the `Cargo.toml`, it will assume `build.rs` is a build script unless `package.build = false`. Just for completeness I also made `build = true` mean the same as `build = "build.rs"` but I'm not sure if that is okay or not.
333a798
@bors
Contributor
bors commented Dec 7, 2016

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 333a798 to master...

@bors bors merged commit 1b99491 into rust-lang:master Dec 7, 2016

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@pwoolcoc
Contributor
pwoolcoc commented Dec 9, 2016

@alexcrichton sorry to revive the old thread, just had a question about this. What is the procedure for going back to finish features like this a few releases down the line? Should I open a tracking issue for it? Or just put a reminder in my calendar for March and ping you again after a couple release cycles?

@alexcrichton
Member

@pwoolcoc oh we unfortunately don't have a super principled way of handling this in Cargo. For now though want to open a tracking issue here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment