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

Consider post-build scripts, too #1894

Closed
larsbergstrom opened this issue Aug 11, 2015 · 8 comments
Closed

Consider post-build scripts, too #1894

larsbergstrom opened this issue Aug 11, 2015 · 8 comments
Labels
A-configuration Area: cargo config files and env vars

Comments

@larsbergstrom
Copy link

There are many actions that can be taken after the build that require custom steps:

  • Making an installer (.deb / .dpkg / .apk / .msi / etc.)
  • Codesigning the binary
  • Uploading the output to an S3 bucket

While these can (and presumably are) done in larger projects by the autotools or CMake solution that is driving Cargo, it might be nice to be able to do it in Cargo itself instead of relying on the project's build runner.

@steveklabnik
Copy link
Member

I would argue that many of these would just be additional Cargo commands that invoke 'build' first.

@larsbergstrom
Copy link
Author

I'm not sure how that works if you have multiple of them (e.g., cargo-sign the binary, then cargo-package the signed binary, then cargo-upload the package), but possibly I'm just being dense, as I haven't been able to figure out how to work custom Cargo commands into Servo's build process yet (because we'd want to build them during the build process, but then they have to be on the PATH, which is... awkward).

@steveklabnik
Copy link
Member

well, I'm thinking something like https://github.com/pwoolcoc/cargo-do, which lets you invoke multiple commands. So you'd write a cargo package that creates a .deb, but makes sure to invoke cargo build before it.

basically, in my mental model, 'cargo foo' is the equivalent of a foo task in a Makefile.

@alexcrichton alexcrichton added the A-configuration Area: cargo config files and env vars label Aug 12, 2015
@alexcrichton
Copy link
Member

I'm also not sure that this fits well into a manifest per se. It goes a bit against the idea that Cargo's not "yet another build system" but rather just a tool to build with. I could imagine small scripts being available in separate locations and you just cd into them and run cargo run perhaps from a build system to automate these various tasks.

Some thorny questions I can think of are:

  • Are post-build scripts always run when the build finishes? Only when it's a top-level package?
  • What if you don't want to run the scripts? For example I may not always want to build a .deb on all platforms all the time.
  • What about dependencies for post-build scripts? Should they always be built or is it a separate dependencies section in Cargo.toml?

Using a separate crate altogether driven from a different location seems like a nice answer to many of these questions perhaps?

@larsbergstrom
Copy link
Author

I think using a separate crate is fine. I'm glad to have some guidance around it, as we've had a bunch of discussion on how to design these things in #servo and #cargo (and with @tomaka), so it's good to put a nail in it.

Feel free to close the issue if you think there's nothing more to discuss!

@steveklabnik
Copy link
Member

npm has a 'scripts' feature: https://docs.npmjs.com/misc/scripts

@alexcrichton
Copy link
Member

Ok for now I think I'm in camp "use an external build tool to script after the build finishes", but we can certainly perhaps explore options here if the need becomes more pressing. We'll probably never do a script feature like npm does (e.g. not cross platform), but we could certainly add the ability to add more Rust scripts which hook into the build process.

@kornelski
Copy link
Contributor

Related discussion: #545

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-configuration Area: cargo config files and env vars
Projects
None yet
Development

No branches or pull requests

4 participants