4 ms·

I disagree about dependency management. Let's say, to avoid reinventing the wheel, I decided to use GLib for cross-platform threading. How do I add GLib as a de

I disagree about dependency management. Let's say, to avoid reinventing the wheel, I decided to use GLib for cross-platform threading. How do I add GLib as a dependency to my C project? Now compare it to adding Tokio as a dependency to my Rust project, which is entirely trivial.

rightbyte 5y ago
> How do I add GLib as a dependency to my C project? Use symbol versioning. Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers for Rust's only and it is not really surprising that he felt that the maintainer burden decreased. As soon as Rust gets broad adaption I guess there will be subtly incompatible compiler vendors in Rust too.
- masklinn 5y ago
  > Use symbol versioning. That doesn't mean anything. > Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to.
  - jcelerier 5y ago
    > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. No, people are just inflicting that upon themselves for no good reason. I ship software built with the same clang / libc++ toolchain targetting Mac / Windows / Linux and things works absolutely fine.
    - masklinn 5y ago
      > I ship software Is it an open-source library?
  - rightbyte 5y ago
    > That doesn't mean anything. I meant that you can specify symbol versions to link to glibc specifically. https://sourceware.org/binutils/docs/ld/VERSION.html https://sourceware.org/binutils/docs/ld/VERSION.html > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. He could have used gcc on different platforms too. He writes: "the platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess" I.e. his problem could have been solved by sticking to one compiler, be it Rust or Clang ...
    - jcranmer 5y ago
      > I meant that you can specify symbol versions to link to glibc specifically. sanxiyn was talking about GLib, not glibc, and these are two very different projects...
    - masklinn 5y ago
      > I meant that you can specify symbol versions to link to glibc specifically. You're confusing glibc and GLib... > He could have used gcc on different platforms too. That certainly would have solved the multiple platform issue, I'm sure gcc has great and easy support for producing VS-compatible dlls, and that there's nothing an ios dev likes to hear more than "you can use GCC to compile libimagequant".
- pornel 5y ago
  I don't think that fragmentation is a given. Other implementations may never take off. Python, Node.js, Java, PHP, C#, Golang, Ruby are all more popular and older than Rust, and did not develop fragmentation like C. They have one dominant target, and other implementations have to follow it, or die. Rust's situation is closer to these languages than to C. But even if there were serious contenders, Rust has already established a strong baseline: there are over 70,000[1] packages that require Rust+Cargo in their current form. A viable alternative has to support them, or it will be niche like mrustc is. [1]: https://lib.rs/stats https://lib.rs/stats
  - rightbyte 5y ago
    Ye that is true (isn't Java a bad example though with Google-Java, OpenJdk vs BigEnterpriseJdk etc?).
    - masklinn 5y ago
      Java could have been a good example, but Sun had a rather strict validation process for calling something Java. Furthermore, there are big difference in philosophy with C: 1. IB and UB are not considered normal parts of specifications, meaning there's way less opportunity for originality in the interpretation of the specifications 2. there tends to be an ur-implementation, and notable divergences from that tends to be interpreted as either a bug in the other implementation(s) or a lack of specification to be resolved between all implementations Rust only has UB in unsafe (AFAIK), which greatly limits implementation flexibility in terms of observable behaviour; and the reference implementation would very much be considered the reference implementation, so I expect e.g. rust-gcc will be sticking close to the reference implementation and behavioural divergence will either be fixed to match, or will lead to more precise specification and both implementations converging. Probably eventually with, if not a Sun-style validation suite, a Ruby-style Spec Suite (https://github.com/ruby/spec https://github.com/ruby/spec).
pjmlp 5y ago
You use cmake,vcpkg or conan, or better yet C11.
- maxwell86 5y ago
  Setting up CMake to support dozen hardware architectures and operating systems (and cross compiling), have targets for basic stuff like code formating, linters, running tests with/without valgrind, sanitizers, etc. generating code coverage instrumentation, etc. used to be a huge time sync. For projects using CMake, I'd argue that one of the main features of Rust is that it enables to spend all that time into adding actual functionality to your programs.
  - pjmlp 5y ago
    I doubt that cargo covers all those scenarios as well, given how Google and others have gone implementing their own replacements to cover exactly such kind of workflows.
    - maxwell86 5y ago
      > I doubt that cargo covers all those scenarios as well * cross compilation: cargo --target=... , you can also cross compile and then run tests for a different target easily (by running them with qemu or in a VM, or via USB in an actual phone or embedded device, etc.) * formating: cargo fmt * linters: cargo clippy * valgrind: cargo valgrind * sanitizers: RUSTFLAGS="-Zsanitizer=..." cargo test builds and runs tests with sanitizers * code coverage: cargo tarpaulin and that's just for the basics. I've seen teams spending weeks on CMake and only being able to set a subset of these up. There are many others, like dumping the inline assembly of a function in a big project (cargo asm function_name), dependency management, etc. As an ex CMake developer and CMake user for >10 years, I'm happy to work on Rust full time just for the benefit of not having to use CMake ever again.
      - Arch-TK 5y ago
        >I've seen teams spending weeks on CMake and only being able to set a subset of these up. Aside from the fact that formatting has nothing to do with building (or development for that matter) that sounds like either a CMake issue or an issue I described in another comment where a problem is identified, a solution is hypothesized, and an attempt is made to implement the solution, all without ever considering if either a: the problem identified is a problem or the right problem, b: the solution hypothesized is the only or best solution and c: if the implementation is implementing the solution or not. >As an ex CMake developer and CMake user for >10 years, I'm happy to work on Rust full time just for the benefit of not having to use CMake ever again. There are other options than CMake.
Arch-TK 5y ago
> How do I add GLib as a dependency to my C project? You document in your documentation (or some metadata file format of your particular liking) the fact that your project requires GLib and which versions of GLib it supports (hopefully GLib supports semver). Then you take that version, feed it to pkg-config with the right version information and feed that into your build process. Depending on your build setup it may be as simple as putting it in your cargo.toml. Unlike with cargo, you also get to chose as a person compiling the project whether you want the code to statically compile a version of your choosing or just link against whatever your distribution provides.
- maxwell86 5y ago
  Your first two sentences: > You document in your documentation (or some metadata file format of your particular liking) the fact that your project requires GLib and which versions of GLib it supports (hopefully GLib supports semver). Then you take that version, feed it to pkg-config with the right version information and feed that into your build process. refute the subsequent claim: > Depending on your build setup it may be as simple as putting it in your cargo.toml. It isn't as simple, cause you have to do more. This glosses over support for operating systems that lack pkg-config, so in practice it is more complicated than that.
  - Arch-TK 5y ago
    >It isn't as simple, cause you have to do more. No? "or some metadata file format of your particular liking" is the sentence which includes "depending on your build setup it may be as simple as putting it in your cargo.toml". Unless you disagree with the whole concept. More importantly, adding dependencies doesn't need to be that easy given that you should focus on not having very many of them in the first place. This doesn't change the fact that it CAN be that easy. >This glosses over support for operating systems that lack pkg-config, so in practice it is more complicated than that. There's one system which doesn't really natively integrate well with pkg-config, that's windows, for windows the build instructions can simply be: cross compile from another operating system or build using a unix envirionment for wibdows. It's not that hard and for the average joe not willing to do this it's absolutely trivial to provide precompiled binaries.

rightbyte 5y ago

> How do I add GLib as a dependency to my C project? Use symbol versioning. Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers for Rust's only and it is not really surprising that he felt that the maintainer burden decreased. As soon as Rust gets broad adaption I guess there will be subtly incompatible compiler vendors in Rust too.

masklinn 5y ago
> Use symbol versioning. That doesn't mean anything. > Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to.
- jcelerier 5y ago
  > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. No, people are just inflicting that upon themselves for no good reason. I ship software built with the same clang / libc++ toolchain targetting Mac / Windows / Linux and things works absolutely fine.
  - masklinn 5y ago
    > I ship software Is it an open-source library?
- rightbyte 5y ago
  > That doesn't mean anything. I meant that you can specify symbol versions to link to glibc specifically. https://sourceware.org/binutils/docs/ld/VERSION.html https://sourceware.org/binutils/docs/ld/VERSION.html > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. He could have used gcc on different platforms too. He writes: "the platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess" I.e. his problem could have been solved by sticking to one compiler, be it Rust or Clang ...
  - jcranmer 5y ago
    > I meant that you can specify symbol versions to link to glibc specifically. sanxiyn was talking about GLib, not glibc, and these are two very different projects...
  - masklinn 5y ago
    > I meant that you can specify symbol versions to link to glibc specifically. You're confusing glibc and GLib... > He could have used gcc on different platforms too. That certainly would have solved the multiple platform issue, I'm sure gcc has great and easy support for producing VS-compatible dlls, and that there's nothing an ios dev likes to hear more than "you can use GCC to compile libimagequant".
pornel 5y ago
I don't think that fragmentation is a given. Other implementations may never take off. Python, Node.js, Java, PHP, C#, Golang, Ruby are all more popular and older than Rust, and did not develop fragmentation like C. They have one dominant target, and other implementations have to follow it, or die. Rust's situation is closer to these languages than to C. But even if there were serious contenders, Rust has already established a strong baseline: there are over 70,000[1] packages that require Rust+Cargo in their current form. A viable alternative has to support them, or it will be niche like mrustc is. [1]: https://lib.rs/stats https://lib.rs/stats
- rightbyte 5y ago
  Ye that is true (isn't Java a bad example though with Google-Java, OpenJdk vs BigEnterpriseJdk etc?).
  - masklinn 5y ago
    Java could have been a good example, but Sun had a rather strict validation process for calling something Java. Furthermore, there are big difference in philosophy with C: 1. IB and UB are not considered normal parts of specifications, meaning there's way less opportunity for originality in the interpretation of the specifications 2. there tends to be an ur-implementation, and notable divergences from that tends to be interpreted as either a bug in the other implementation(s) or a lack of specification to be resolved between all implementations Rust only has UB in unsafe (AFAIK), which greatly limits implementation flexibility in terms of observable behaviour; and the reference implementation would very much be considered the reference implementation, so I expect e.g. rust-gcc will be sticking close to the reference implementation and behavioural divergence will either be fixed to match, or will lead to more precise specification and both implementations converging. Probably eventually with, if not a Sun-style validation suite, a Ruby-style Spec Suite (https://github.com/ruby/spec https://github.com/ruby/spec).

pjmlp 5y ago

You use cmake,vcpkg or conan, or better yet C11.

maxwell86 5y ago
Setting up CMake to support dozen hardware architectures and operating systems (and cross compiling), have targets for basic stuff like code formating, linters, running tests with/without valgrind, sanitizers, etc. generating code coverage instrumentation, etc. used to be a huge time sync. For projects using CMake, I'd argue that one of the main features of Rust is that it enables to spend all that time into adding actual functionality to your programs.
- pjmlp 5y ago
  I doubt that cargo covers all those scenarios as well, given how Google and others have gone implementing their own replacements to cover exactly such kind of workflows.
  - maxwell86 5y ago
    > I doubt that cargo covers all those scenarios as well * cross compilation: cargo --target=... , you can also cross compile and then run tests for a different target easily (by running them with qemu or in a VM, or via USB in an actual phone or embedded device, etc.) * formating: cargo fmt * linters: cargo clippy * valgrind: cargo valgrind * sanitizers: RUSTFLAGS="-Zsanitizer=..." cargo test builds and runs tests with sanitizers * code coverage: cargo tarpaulin and that's just for the basics. I've seen teams spending weeks on CMake and only being able to set a subset of these up. There are many others, like dumping the inline assembly of a function in a big project (cargo asm function_name), dependency management, etc. As an ex CMake developer and CMake user for >10 years, I'm happy to work on Rust full time just for the benefit of not having to use CMake ever again.
    - Arch-TK 5y ago
      >I've seen teams spending weeks on CMake and only being able to set a subset of these up. Aside from the fact that formatting has nothing to do with building (or development for that matter) that sounds like either a CMake issue or an issue I described in another comment where a problem is identified, a solution is hypothesized, and an attempt is made to implement the solution, all without ever considering if either a: the problem identified is a problem or the right problem, b: the solution hypothesized is the only or best solution and c: if the implementation is implementing the solution or not. >As an ex CMake developer and CMake user for >10 years, I'm happy to work on Rust full time just for the benefit of not having to use CMake ever again. There are other options than CMake.

Arch-TK 5y ago

> How do I add GLib as a dependency to my C project? You document in your documentation (or some metadata file format of your particular liking) the fact that your project requires GLib and which versions of GLib it supports (hopefully GLib supports semver). Then you take that version, feed it to pkg-config with the right version information and feed that into your build process. Depending on your build setup it may be as simple as putting it in your cargo.toml. Unlike with cargo, you also get to chose as a person compiling the project whether you want the code to statically compile a version of your choosing or just link against whatever your distribution provides.

maxwell86 5y ago
Your first two sentences: > You document in your documentation (or some metadata file format of your particular liking) the fact that your project requires GLib and which versions of GLib it supports (hopefully GLib supports semver). Then you take that version, feed it to pkg-config with the right version information and feed that into your build process. refute the subsequent claim: > Depending on your build setup it may be as simple as putting it in your cargo.toml. It isn't as simple, cause you have to do more. This glosses over support for operating systems that lack pkg-config, so in practice it is more complicated than that.
- Arch-TK 5y ago
  >It isn't as simple, cause you have to do more. No? "or some metadata file format of your particular liking" is the sentence which includes "depending on your build setup it may be as simple as putting it in your cargo.toml". Unless you disagree with the whole concept. More importantly, adding dependencies doesn't need to be that easy given that you should focus on not having very many of them in the first place. This doesn't change the fact that it CAN be that easy. >This glosses over support for operating systems that lack pkg-config, so in practice it is more complicated than that. There's one system which doesn't really natively integrate well with pkg-config, that's windows, for windows the build instructions can simply be: cross compile from another operating system or build using a unix envirionment for wibdows. It's not that hard and for the average joe not willing to do this it's absolutely trivial to provide precompiled binaries.