Add Debian template for 'cargo' build type#774
Conversation
Signed-off-by: Jorge Perez <jjperez@ekumenlabs.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## cottsay/cargo #774 +/- ##
================================================
Coverage ? 52.24%
================================================
Files ? 57
Lines ? 6969
Branches ? 1206
================================================
Hits ? 3641
Misses ? 2983
Partials ? 345 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Signed-off-by: Jorge Perez <jjperez@ekumenlabs.com>
Signed-off-by: Jorge Perez <jjperez@ekumenlabs.com>
Blast545
force-pushed
the
blast545/cargo_debian_template
branch
from
d6f4f07 to
ac4dc6f
Compare
| if [ -f "@(InstallationPrefix)/setup.sh" ]; then . "@(InstallationPrefix)/setup.sh"; fi | ||
| cargo test || true | ||
|
|
||
| override_dh_auto_install: |
There was a problem hiding this comment.
By overriding dh-cargo's install we're missing out on this whole section, which is responsible for installing the unpacked crate to <prefix>/share/cargo/registry/
(sorry I couldn't figure out how to link to dh-cargo's actual upstream source code, but this fork/mirror seems to work)
There was a problem hiding this comment.
Unfortunately the output path is hard-coded in that snippet, so I wonder if the best thing to do is maybe to let the install happen to /usr/share/cargo/registry and then blindly move the results (if any) to @(InstallationPrefix)/share/cargo/registry.
There was a problem hiding this comment.
I think there's no simple way to rely on their code to do what they do with our custom naming/path needs, so I think we can just try to go on our own route. At least for the proof of concept
Co-authored-by: Scott K Logan <logans@cottsay.net>
Co-authored-by: Scott K Logan <logans@cottsay.net>
Signed-off-by: Jorge Perez <jjperez@ekumenlabs.com>
…bloom into blast545/cargo_debian_template
Signed-off-by: Jorge Perez <jjperez@ekumenlabs.com>
|
Do not review, iterating on this one. After I recalled that crates are separated debians/libs, see: https://github.com/deepin-community/dh-cargo/blob/00d6ee3b093ef085d02302bc9fc1e4bdc821fc14/cargo.pm#L177-L186, I created a more complete example for testing this PR and it's not completely working yet. |
|
Ok, I tested this with: https://github.com/Blast545/testing_colcon_ros_buildfarm_cargo. There's a lot of llm generated doc, but the interesting parts of the setup that are worth checking: Some dependencies we need in the buildfarm to build cargo stuff: https://github.com/Blast545/testing_colcon_ros_buildfarm_cargo/tree/main#patches-applied-to-the-venv-install rosdistro/distribution.yaml: https://github.com/Blast545/testing_colcon_ros_buildfarm_cargo/blob/main/configs/rosdistro/rolling/distribution.yaml The rust crates under the test: |
| HAS_LIB=$$(printf '%s' "$$META" | python3 -c "import sys,json;p=json.load(sys.stdin)['packages'][0];L={'lib','rlib','dylib','cdylib','staticlib','proc-macro'};print(int(any(k in L for t in p['targets'] for k in t['kind'])))") ; \ | ||
| HAS_BIN=$$(printf '%s' "$$META" | python3 -c "import sys,json;p=json.load(sys.stdin)['packages'][0];print(int(any('bin' in t['kind'] for t in p['targets'])))") ; \ |
There was a problem hiding this comment.
I'm not sure if there's a simpler way to detect if a specific package has libraries or is it only binary.
3 participants
Adds a Debian/Ubuntu packaging template for the
cargobuild_type, mirroring the scope of #763 (RPM cargo template).cargo auditable(compressed JSON in a.dep-v0ELF section)