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

Rustpkg needs to support invoking the default build logic in a package script #6401

Closed
catamorphism opened this issue May 10, 2013 · 2 comments
Milestone

Comments

@catamorphism
Copy link
Contributor

Sub-bug of #5677

In pkg.rs, there has to be a way to invoke the default build logic. Either provide a library function in librustpkg that does this, or make rustpkg automatically invoke it after executing the contents of pkg.rs (with a way to turn that off). I guess I prefer the first option, but don't care that much.

@ghost ghost assigned catamorphism May 10, 2013
@metajack
Copy link
Contributor

Thinking about this more, I think the first option is preferable if we keep the fn main() { ... } in pkg.rs.

In order to support both pre-build logic and post-build logic otherwise you'd need to either disallow post-build logic without supressing default behavior, or you could have three functions with default implementations: prebuild, build, and postbuild, where normally people are only overiding the first one.

Since keeping main is the easiest path forward and doesn't close any other paths in the future, option one seems to be the way to go.

@catamorphism
Copy link
Contributor Author

Agreed.

bors added a commit that referenced this issue Jun 27, 2013
r? @brson (or @graydon if available) rustpkg/api.rs provides functions intended for package scripts to call.
It will probably need more functionality added to it later, but this is
a start.

Added a test case checking that a package script can use the API.

Closes #6401
yjh0502 pushed a commit to yjh0502/rust that referenced this issue Jun 28, 2013
rustpkg/api.rs provides functions intended for package scripts to call.
It will probably need more functionality added to it later, but this is
a start.

Added a test case checking that a package script can use the API.

Closes rust-lang#6401
@catamorphism catamorphism removed their assignment Jun 16, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 20, 2020
📌 Pin Clippy to a nightly 📌

changelog: Pin Clippy to a specific nightly version (No more master/custom toolchain required to compile Clippy)

Addresses partially rust-lang#5561. As proposed there in [this comment](rust-lang/rust-clippy#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling.

Open questions:
* When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that.
* When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful.
* Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas?
* I'm not sure if this affects the release process in any way.
* ???

`@rust-lang/clippy` thoughts?

r? `@flip1995`
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 a pull request may close this issue.

2 participants