Hi ports@, I've been working on a port for Cargo, the package manager for the Rust language. I already know this isn't ready for inclusion as is, but I was hoping to solicit some feedback on the approach I've taken so far. The port can be downloaded here:
https://steven.bucket.nchr.io/openbsd-ports/cargo-bootstrap.tar.gz That tarball is intended to be extracted from within /usr/ports/devel/. It makes use of dhuseby's cargo-bootstrap tool to perform the legwork, which makes dependency checking and feature resolution a lot easier: https://github.com/dhuseby/cargo-bootstrap This port is capable of building a cargo binary as is. However, the libgit2 crate (Rust's term for a software module) links against an embedded version of libgit2 rather than the version from ports. devel/libgit2 will need to be updated before this can be fixed, and it's the main reason why this port isn't completely ready yet. I seem to have picked a tricky one for my first port, so I have a few questions: 1. I'm installing the cargo binary into /usr/local/libexec/cargo-bootstrap/, to avoid it accidentally ending up in the default $PATH. My intent is that the bootstrapped cargo binary can be used to build proper ports of all its dependencies, and eventually cargo itself. Does this seem like a reasonable plan? 2. I'm not sure if ONLY_FOR_ARCHS is necessary. lang/rust has ONLY_FOR_ARCHS = amd64, and since cargo depends on rust, it seems natural to just rely on the fact that we can run on any arch supported by rust. I've left it out for now, but should that be included? 3. Should the second-level name be something like rs-cargo instead of cargo? I notice other programming languages have their own 2-character prefix for package names; is there any convention there for new languages? 4. portcheck complains about lines longer than 80 characters in the Makefile, but I can't see any way to shorten these (they're just DISTFILES with very long version numbers). Is that OK to leave as is? 5. portcheck also complains about an extra file under patches/. Is there a better way to patch secondary DISTFILES than with the manual patch invocation I've got in do-build? I'd appreciate any feedback. Thanks, Steven.