On Sat, 03 Feb 2018, n...@n0.is wrote: > Now I'm going to sleep on this: > > ;; Rust doesn't have a stable ABI yet. Because of this > ;; Cargo doesn't have a search path for binaries yet. > ;; Until this changes we are working around this by > ;; distributing crates as source and replacing > ;; references in Cargo.toml with store paths. > (copy-recursively "src" (string-append rsrc "/src")) > (touch (string-append rsrc "/.cargo-ok")) > (generate-checksums rsrc src) > (install-file "Cargo.toml" rsrc) > ;; When the package includes executables we install > ;; it using cargo install. This fails when the crate > ;; doesn't contain an executable. > (if (file-exists? "Cargo.lock") > (zero? (system* "cargo" "install" "--root" out)) > (begin > (mkdir out) > #t)))) > > > ... and look into libc after the 8th again. > Maybe someone of you has an epiphany on the libc crate until > then.
One more thing before I take this break: Can someone explain to me what the purpose of the Cargo.lock is? Apparently libs ignore it and binaries track it. > http://crates.io/faq.html#why-do-binaries-have-cargo.lock-in-version-control,-but-not-libraries? > says: > > The purpose of a Cargo.lock is to describe the state of the world at the > time of a successful build. It is then used to provide deterministic > builds across whatever machine is building the project by ensuring that > the exact same dependencies are being compiled. and the Cargo.lock of libc is long. My assumption was it has no real dependencies. 0. Nada. Nichts. I think I have to read more into rust packaging, in the meantime it would be good if someone with reference to the first email and the email I referenced in there could reply about their knowledge of the rust/cargo build system. I'm okay with stabbing in the dark, but shared expertise is good. -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
