4 ms·

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

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.

ridiculous_fish 5y ago
How does Rust handle problems like "call this function if it exists?" Is there support in build scripts?
- comex 5y ago
  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.
saagarjha 5y ago
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.
- ridiculous_fish 5y ago
  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 https://doc.rust-lang.org/src/std/sys/unix/os.rs.html#38
  - steveklabnik 5y ago
    (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.)
  - nicoburns 5y ago
    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.
- saghm 5y ago
  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.
- pjmlp 5y ago
  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.
  - ithkuil 5y ago
    Google's bazel/blaze predates rust. It has the advantage of supporting multiple languages
    - jcelerier 5y ago
      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
      - mtzet 5y ago
        That's a feature, no?
      - ithkuil 5y ago
        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"], ) """, )
  - zeusk 5y ago
    At Microsoft, we do use cargo internally but we make use of an internal crate registry.
pjmlp 5y ago
Now try to integrate it on mixed codebase like Android or Fuchsia.

ridiculous_fish 5y ago

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

comex 5y ago
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.

saagarjha 5y ago

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.

ridiculous_fish 5y ago
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 https://doc.rust-lang.org/src/std/sys/unix/os.rs.html#38
- steveklabnik 5y ago
  (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.)
- nicoburns 5y ago
  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.
saghm 5y ago
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.
pjmlp 5y ago
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.
- ithkuil 5y ago
  Google's bazel/blaze predates rust. It has the advantage of supporting multiple languages
  - jcelerier 5y ago
    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
    - mtzet 5y ago
      That's a feature, no?
    - ithkuil 5y ago
      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"], ) """, )
- zeusk 5y ago
  At Microsoft, we do use cargo internally but we make use of an internal crate registry.

pjmlp 5y ago

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