-
-
Notifications
You must be signed in to change notification settings - Fork 11.4k
Proposal: add cargo to rust formula #33322
Comments
I'd be 👍 on this but at last check Cargo wasn't stable yet? Or at least doesn't have a stable release? Having to clone the git and then build Cargo from source manually is a bit of an additional pain, especially when we could be cloning slightly different Cargo sources into Rust on a day to day basis. Cargo also has 4 major dependencies that Rust doesn't. The upside of |
That's a good point I overlooked: there aren't even any 0.x releases of Cargo from what I can see 😦. Maybe I should close this until they start tagging versions? |
I'd await feedback from one of the maintainers to be sure, but my gut feeling is that Homebrew won't be able to support Cargo until they start tagging releases that both work every time and don't make any sudden, unexpected changes outside of that release schedule. |
Last time I checked Cargo can't be compiled with current Rust version, that's why It is recommended to use Cargo with nightly Rust |
Alright then, we should revisit this once a release of Cargo is tagged. |
SGTM 👍 |
Now when rust 1.0.0 beta came out, it's time to review this issue |
Are Cargo tagging usable releases yet? |
@DomT4 nope :( |
I guess that's the primary problem. We'd probably need tagged releases that won't break against Rust stable. |
Seems like somehow cargo has a peculiar versioning scheme:
That is, a cargo release is whatever gets packaged within a rust release. Currently (rust 1.0.0-beta) this is (look for the SHA1):
|
There are two distinct situations one may have to consider:
Which one are we talking about here? Since cargo needs to fetch a cargo snapshot to build itself, it may not be that far of a stretch to allow the build process to fetch a nightly rust (as done by FWIW here's what I came up with, which builds the only cargo tag release (0.0.1-pre), as well as HEAD: class Cargo < Formula
homepage "https://crates.io"
head "https://github.com/rust-lang/cargo", :using => :git
version "0.0.1-pre"
url "https://github.com/rust-lang/cargo/archive/v0.0.1-pre.tar.gz"
sha256 "3c61260e8511fec344033a888f5dfcf3f0f13de86eecffd5903023082f475e5a"
option "with-local-rust", "Build with Homebrew's rust"
depends_on "cmake" => :build
depends_on "python" => :build
depends_on "pkg-config" => :build
depends_on "curl" => :build unless build.with? "local-rust"
depends_on "openssl"
depends_on "rust"
def install
if build.head?
system "git", "submodule", "update", "--init"
end
args = []
if build.with? "local-rust"
args << "--local-rust-root=#{Formula["rust"].opt_prefix}"
else
system "./.travis.install.deps.sh"
args << "--local-rust-root=\"$PWD\"/rustc"
end
args << "--prefix=#{prefix}"
system "./configure", *args
system "make"
system "make", "install"
rm_rf prefix/"lib/rustlib/components"
rm_rf prefix/"lib/rustlib/install.log"
rm_rf prefix/"lib/rustlib/rust-installer-version"
rm_rf prefix/"lib/rustlib/uninstall.sh"
end
test do
system "#{bin}/cargo"
end
end |
Seems to me |
My thought exactly (way more inline with upstream), but a separate formula was best to get acquainted with the build sequence. |
👍 Would you be able to submit a pull request? I can't promise we'll be able to merge it immediately but it definitely seems like something we'll want. |
Will do. |
Rust formula including cargo is theoretically ready: waiting for rust build to complete, which takes approximately ages and a half. |
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it may be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile, but this requires patching of .travis.install.deps.sh, that currently unconditionally downloads its stuff. Simply putting the cargo snapshot in the right place ($(TARGET_ROOT)/snapshot/cargo) will certainly make the makefile happy, as long as the proper filename unmangling is done (see src/etc/dl-snapshot.py). Still, configure wants to probe for python. Staying KISS, no patching has been done here: make it work, make it right, make it fast.
Off we go onto the aforementioned Pull Request. |
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it may be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile, but this requires patching of .travis.install.deps.sh, that currently unconditionally downloads its stuff. Simply putting the cargo snapshot in the right place ($(TARGET_ROOT)/snapshot/cargo) will certainly make the makefile happy, as long as the proper filename unmangling is done (see src/etc/dl-snapshot.py). Still, configure wants to probe for python. Staying KISS, no patching has been done here: make it work, make it right, make it fast.
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component.
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component.
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component.
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component.
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component.
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component.
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component.
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component.
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component.
This follows discussion on #33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component. Closes #38674. Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
This follows discussion on Homebrew#33322, where it has been hypothesized that the best course of action may very well be to include cargo in the rust formula. Reasons include: - upstream packages releases with cargo - cargo has no formal versioning rules, merely binding a particular cargo nightly to a given rust release - cargo needs a non feature-gated rust to build - cargo needs to fetch cargo to bootstrap itself (at the make stage) The most practical way to get the cargo version bound to a rust release is to download a binary rust release and run cargo -V, which shows the SHA1 it was built from. This is what has been done for the beta. Alternatively, building with --HEAD relaxes all version constrains and builds both from their respective master HEADs. Curl is a dependency of .travis.install.deps.sh while both curl and python are a dependency of make (via src/etc/dl-snapshot.py) to download a cargo snapshot. Each one makes respective use of a src/rustversion.txt and a src/snapshots.txt file, combined with some very lighteight processing, to find the required downloads. Thus it is be possible to include fetched downloads as resources to improve cacheability and reduce the dependency profile as long as one maintains consistency between each build component. Closes Homebrew#38674. Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
I'm not sure if homebrew would prefer this as a separate formula or
--with-cargo
as an option within the rust formula.For comparison:
My vote goes to installing cargo by default within the rust formula.
The text was updated successfully, but these errors were encountered: