Re: 77 Rust Crates, fluid, roboto-font, libpsyc rust bindings

[David Craven]

> I understand the concerns of David Craven regarding
> ‘cargo-build-system’, though OTOH I’m tempted to think
> ‘cargo-build-system’ is probably not so bad if it managed to build all
> this.  ;-)  But anyway, I’ll David and you figure out what the best
> approach is!

I haven't inspected all the patches, but I don't think it's possible
that any package was actually built (unless danny's patch was
applied). All the build-system does with these packages is recursively
download the rust-psych dependency tree without building anything.
This would not show any problems with some crates requiring a nightly
rustc, or circular dependencies, or version mismatches (like requiring
an older semver major version or multiple versions of the same
package).

The downside of doing it like this is that we can't run tests on the
dependencies. But I think that building binaries like cargo that have
locked dependencies side steps all the problems mentioned above, and
would be a big milestone. It would allow us to do cool things like
patch crates with security fixes; and c wrapper crates like
rust-pkg-config, rust-cmake, rust-openssl, etc. could
declare/propagate/retain their c dependencies directly.


Danny has been exploring a different (or complementary) approach that
would allow running the tests on the crates and solves the above
issues manually. I currently think that doing this manually would make
packaging and much more important updating packages a large amount of
manual work, but I am open to reconsider if someone shows this to be a
surmountable task.

Another issue with Danny's approach is that as it is now, I don't see
an immediate advantage of running tests on dependencies of a package
before we have managed to build the package. The reason being that
trying to use the latest versions of all packages recursively might
yield big issues when trying to build the final thing even if all
tests passed on the individual crates. This results in false
confidence in the taken path and I don't think it can be considered a
reliable intermediate step to packaging a rust package, as it would be
in other build-systems. At least not until someone has provided
evidence by showing at least one counter example.