Hacker News Reader

Comment by tempest_ | Hacker News Reader

Honestly the modern build system is my favourite feature of rust.

No messing with autoconfs, and make files that spit out some random gcc error I have to debug.

To be fair however I am also not too interested in c++ and its 30 years of foot guns either so take it for what its worth.

View on HN

In my experience Rust’s ability to rid itself from autoconf comes not because of any inherent benefits but because Rust code typically does not support systems where autoconf would really be required. For the mostly sane platform differences, the popular ones are probably hardcoded in some dependency crate with “-std” in its name so you don’t have to see it, unless of course it turns out to not support your less common platform or the check is broken, in which case you lob a GitHub issue at them and they deal with it.

Rust does support a surprisingly deep set of platforms, but it achieves this by baking platform-specific knowledge into Rust itself. See for example how it finds errno, it's just a big list of special cases. It is pleasant to not need the configure scripts, but a downside is that no new platform can participate without first patching Rust.

https://doc.rust-lang.org/src/std/sys/unix/os.rs.html#38

(Into the standard library, not into Rust itself. Anyone can write this, you don't need to patch Rust first just to call some functions.)

I believe you can write your own completely separate standard library if you want to (much like each platform typically has it's own libc). It's just that it's easier to manage the first-party supported platforms as one codebase.

I think there's an argument to be made that some developers might be willing to sacrifice portability to some lesser-used platforms in order to make the ecosystem a bit cleaner for the platforms it does support. This is definitely a tradeoff though, so it make sense and is good that different ecosystems make difference choices here, as it allows people to choose whichever suits them best.

Yes, cargo is perfect if you are willing to always compile from source, everything is Rust and one is willing to deal with everything else themselves in build.rs scripts.

Google and Microsoft aren't using cargo on their projects, rather had to come up with their own build tool.

Google's bazel/blaze predates rust. It has the advantage of supporting multiple languages

and is pretty much unuseable in the traditional unix setting where you are supposed to vendor nothing and use all the libraries of the OS however broken they may be

That's a feature, no?

That's less a limitation of the build system and more an intentional policy to ensure reproducible binaries etc.

Technically bazel can load any external files, but they must be tracked as workspace dependencies, which is more verbose:

E.g.

    new_local_repository(
        name = "system_libs",
        # pkg-config --variable=libdir x11
        path = "/usr/lib/x86_64-linux-gnu",
        build_file_content = """

cc_library( name = "x11", srcs = ["libX11.so"], visibility = ["//visibility:public"], ) """, )

At Microsoft, we do use cargo internally but we make use of an internal crate registry.

Now try to integrate it on mixed codebase like Android or Fuchsia.

How does Rust handle problems like "call this function if it exists?" Is there support in build scripts?

It doesn't. Indeed, when it comes to libc and other system libraries (or really most C libraries in general), the Rust ecosystem relies on hardcoding the ABI of every supported platform. It's theoretically possible to use bindgen (which parses C headers) as a build step, but this is rarely done.

Reply on news.ycombinator.com