Closed mistydemeo closed 12 months ago
With #428 merged, is this now available? The mdbook
states that workspace.metadata.dist.dependencies.<pkg-mgr>.<dep>
should work, is that the case today?
I ask because I am looking to add a step like this in a CI job but adding these keys and running cargo dist genrate
doesn't seem to update .github/workflows/release.yml
We haven't yet released 0.4.0, which is the release that will include this feature. While we may have a prerelease out before then, it'll be a little longer until it's included in a stable release.
Thank you for the reply. I didn't realize that the since <version>
header could include not-yet released versions and didn't look closely enough. Sorry for the extra noise here.
Hi @mistydemeo
May I ask what is the recommended way of proceeding when dependencies are not packaged?
In my situation, I have proper system dependencies for Linux and MacOS with apt/brew (working fine!). For Windows, I have a few lines to run before building my executables (nothing on choco).
I found the "reusable workflow" item in the documentation, but it is not clear to me whether what I would install with such a workflow would persist in the runners of the build artifact matrix later?
Not sure where to ask, but this issue seems related... Have a nice week-end
Right now, users can specify cargo dependencies for their package via
Cargo.toml
, but we don't provide a way for users to specify system packages that need to be present during the build. We should provide a way for developers to specify system packages that will be present on the builders during their build.My current plan is to add a new
system-dependencies
key toCargo.toml
. This allows the user to specify the dependencies per package manager. When we run a build on a system that uses that package manager, we install those dependencies prior to running the build. It looks something like this:Some of these dependencies will end up being required at runtime for users of the software, but not all of them. Some of these dependencies will be build tools such as
cmake
, which are totally unnecessary once the software is built, while others will be libraries that will be dynamically linked against and required by the resulting binary. We should leverage #422 to determine which packages are actually needed at runtime, and inject those packages as dependencies of our package manager manifests such as the Homebrew formula.For Homebrew builds, I plan to use
Brewfile
s andbrew bundle exec
. This will allow us to ensure that the build is able to find Homebrew-provided dependencies even if they end up outside cargo's default search paths with the least fuss.