3 ms·

Let the one without sin throw the first stone. Please describe to us how you do dependency management with C. Also picking C89 over any later iteration is bana

Let the one without sin throw the first stone. Please describe to us how you do dependency management with C. Also picking C89 over any later iteration is bananas.

rustdebacletime 1y ago
I would use a newer version of C, and consider picking C++, if the choice was between C, C++, Ada, and Rust. (If pattern matching would be a large help, I might consider Rust). For C++, there is vcpkg and Conan. While they are overall significantly or much worse options than what Rust offers according to many, in large part due to C++'s cruft and backwards compatibility, they do exist.
- Avamander 1y ago
  > For C++, there is vcpkg and Conan But I asked about C.
  - rustdebacletime 1y ago
    I looked it up, both vcpkg and Conan support C as well as C++, at least according to their own descriptions.
    - Avamander 1y ago
      The way you've described both of those solutions demonstrates perfectly how C package management is an utter mess. You claim to be very familiar with the C ecosystem yet you describe them based on their own description. Not once have you seen them in use? Both of those are also (only) slightly younger than Rust by the way. So after all these decades there's maybe something vaguely tolerable that's also certainly less mature than what even Rust has. Congrats.
      - rustdebacletime 1y ago
        You might be mixing up who you are replying to. I never claimed that C and C++ package management are better than what Rust offers overall. In some regards, Cargo is much better than what is offered in C and C++. I wouldn't ascribe that to a mess, more the difficulty of maintaining backwards compatibility and handling cruft. However, I know of people that have had significant trouble handling Rust. For instance, the inclusion of Rust in bcachefs and handling it in Debian that whole debacle. https://lwn.net/Articles/1035890/ https://lwn.net/Articles/1035890/ They did not have an easy time including Rust software as I read it. Maybe just initial woes, but I have also read other descriptions of distribution maintainers having trouble with integrating Rust software. Dynamic binding complaints? I have not looked into it.
cozzyd 1y ago
> Please describe to us how you do dependency management with C dnf or apt, depending on if Fedora/EL or Debian...
- Avamander 1y ago
  You're always building for the same distribution and release?
  - cozzyd 1y ago
    A small number of slowly moving variants, but for a given deployment it's roughly stable. I suppose I missed the important case of Yocto though
amiga386 1y ago
> Please describe to us how you do dependency management with C. PKG_CHECK_MODULES([libfoo], [libfoo >= 1.2.3]) AC_CHECK_HEADER([foo.h], ,[AC_MSG_ERROR([Cannot find foo header])]) AC_CHECK_LIB([foo],[foo_open], ,[AC_MSG_ERROR([Cannot find foo library])]) There are additionally versioning standards for shared objects, so you can have two incompatible versions of a library live side-by-side on a system, and binaries can link to the one they're compatible with.
- Avamander 1y ago
  > Cargo always picks the newest version of a dependency, even if that version is incompatible with the version of Rust you have installed. > PKG_CHECK_MODULES([libfoo], [libfoo >= 1.2.3]) This also picks the newest version that might be incompatible with your compiler, if the newer version uses a newer language standard. > You're like "build this please", and it's like "hey I helpfully upgraded this module! oh and you can't build this at all, your compiler is too old granddad" Also possible in the case of your example. > What a bunch of shiny-shiny chasing idiots with a brittle build system. Autoconf as an example of non-brittle build system? Laughable at best.
  - amiga386 1y ago
    This is whataboutism to deflect from Rust's basic ethos being to pull in the latest shiny-shiny. > This also picks the newest version that might be incompatible with your compiler, if the newer version uses a newer language standard. It doesn't, it just verifies what the user has already installed (with apt/yum/dnf) is suitable. It certainly doesn't connect to the network and go looking for trouble. The onus is on library authors to write standard-agnostic, compiler-agnostic headers, and that's what they do: #if __STDC_VERSION__ >= 199901L /* C99 definitions */ #else /* pre-C99 definitions */ #endif For linking, shared objects have their own versioning to allow backwards-incompatible versions to exist simultaneously (libfoo.so.1, libfoo.so.2).
    - Avamander 1y ago
      > This is whataboutism to deflect from Rust's basic ethos being to pull in the latest shiny-shiny. No. You set a bar for Cargo that the solution you picked does not reach either. > It doesn't, it just verifies what the user has already installed (with apt/yum/dnf) is suitable. There's no guarantee that that is compatible with your project though. You might be extra unlucky and have to bring in your own copy of an older version. Plus their dependencies. Perfect example of the pile of flaming garbage that is C dependency "management". We haven't even mentioned cross-compiling! It multiplies all this C pain a hundredfold. > The onus is on library authors to write standard-agnostic, compiler-agnostic headers, and that's what they do: You're assuming that the used feature can be represented in older language standards. If it doesn't, you're forced to at least have that newer compiler on your system. > [...] standard-agnostic, compiler-agnostic headers [...] > For linking, shared objects have their [...] Compiler-agnostic headers that get compiled to compiler-specific calling conventions. If I recall correctly, GCC basically dictates it on Linux. Anyways, I digress. > shared objects have their own versioning to allow backwards-incompatible versions to exist simultaneously (libfoo.so.1, libfoo.so.2). Oooh, that one is fun. Now you have to hope that nothing was altered when that old version got built for that new distro. No feature flag changed, no glibc-introduced functional change. > hey I helpfully upgraded this module! oh and you can't build this at all, your compiler is too old granddad If we look at your initial example again, Cargo followed your project's build instructions exactly and unfortunately pulled in a package that is for some reason incompatible with your current compiler version. To fix this you have the ability to just specify an older version of the crate and carry on. Looking at your C example, well, I described what you might have to do and how much manual effort that can be. Being forced to use a newer compiler can be very tedious. Be it due to bugs, stricter standards adherence or just the fact that you have to do it. In the end, it's not a fair fight comparing dependency management between Rust and C. C loses by all reasonable metrics.

Let the one without sin throw the first stone. Please describe to us how you do dependency management with C. Also picking C89 over any later iteration is bananas.

rustdebacletime 1y ago

I would use a newer version of C, and consider picking C++, if the choice was between C, C++, Ada, and Rust. (If pattern matching would be a large help, I might consider Rust). For C++, there is vcpkg and Conan. While they are overall significantly or much worse options than what Rust offers according to many, in large part due to C++'s cruft and backwards compatibility, they do exist.

Avamander 1y ago
> For C++, there is vcpkg and Conan But I asked about C.
- rustdebacletime 1y ago
  I looked it up, both vcpkg and Conan support C as well as C++, at least according to their own descriptions.
  - Avamander 1y ago
    The way you've described both of those solutions demonstrates perfectly how C package management is an utter mess. You claim to be very familiar with the C ecosystem yet you describe them based on their own description. Not once have you seen them in use? Both of those are also (only) slightly younger than Rust by the way. So after all these decades there's maybe something vaguely tolerable that's also certainly less mature than what even Rust has. Congrats.
    - rustdebacletime 1y ago
      You might be mixing up who you are replying to. I never claimed that C and C++ package management are better than what Rust offers overall. In some regards, Cargo is much better than what is offered in C and C++. I wouldn't ascribe that to a mess, more the difficulty of maintaining backwards compatibility and handling cruft. However, I know of people that have had significant trouble handling Rust. For instance, the inclusion of Rust in bcachefs and handling it in Debian that whole debacle. https://lwn.net/Articles/1035890/ https://lwn.net/Articles/1035890/ They did not have an easy time including Rust software as I read it. Maybe just initial woes, but I have also read other descriptions of distribution maintainers having trouble with integrating Rust software. Dynamic binding complaints? I have not looked into it.

cozzyd 1y ago

> Please describe to us how you do dependency management with C dnf or apt, depending on if Fedora/EL or Debian...

Avamander 1y ago
You're always building for the same distribution and release?
- cozzyd 1y ago
  A small number of slowly moving variants, but for a given deployment it's roughly stable. I suppose I missed the important case of Yocto though

amiga386 1y ago

> Please describe to us how you do dependency management with C. PKG_CHECK_MODULES([libfoo], [libfoo >= 1.2.3]) AC_CHECK_HEADER([foo.h], ,[AC_MSG_ERROR([Cannot find foo header])]) AC_CHECK_LIB([foo],[foo_open], ,[AC_MSG_ERROR([Cannot find foo library])]) There are additionally versioning standards for shared objects, so you can have two incompatible versions of a library live side-by-side on a system, and binaries can link to the one they're compatible with.

Avamander 1y ago
> Cargo always picks the newest version of a dependency, even if that version is incompatible with the version of Rust you have installed. > PKG_CHECK_MODULES([libfoo], [libfoo >= 1.2.3]) This also picks the newest version that might be incompatible with your compiler, if the newer version uses a newer language standard. > You're like "build this please", and it's like "hey I helpfully upgraded this module! oh and you can't build this at all, your compiler is too old granddad" Also possible in the case of your example. > What a bunch of shiny-shiny chasing idiots with a brittle build system. Autoconf as an example of non-brittle build system? Laughable at best.
- amiga386 1y ago
  This is whataboutism to deflect from Rust's basic ethos being to pull in the latest shiny-shiny. > This also picks the newest version that might be incompatible with your compiler, if the newer version uses a newer language standard. It doesn't, it just verifies what the user has already installed (with apt/yum/dnf) is suitable. It certainly doesn't connect to the network and go looking for trouble. The onus is on library authors to write standard-agnostic, compiler-agnostic headers, and that's what they do: #if __STDC_VERSION__ >= 199901L /* C99 definitions */ #else /* pre-C99 definitions */ #endif For linking, shared objects have their own versioning to allow backwards-incompatible versions to exist simultaneously (libfoo.so.1, libfoo.so.2).
  - Avamander 1y ago
    > This is whataboutism to deflect from Rust's basic ethos being to pull in the latest shiny-shiny. No. You set a bar for Cargo that the solution you picked does not reach either. > It doesn't, it just verifies what the user has already installed (with apt/yum/dnf) is suitable. There's no guarantee that that is compatible with your project though. You might be extra unlucky and have to bring in your own copy of an older version. Plus their dependencies. Perfect example of the pile of flaming garbage that is C dependency "management". We haven't even mentioned cross-compiling! It multiplies all this C pain a hundredfold. > The onus is on library authors to write standard-agnostic, compiler-agnostic headers, and that's what they do: You're assuming that the used feature can be represented in older language standards. If it doesn't, you're forced to at least have that newer compiler on your system. > [...] standard-agnostic, compiler-agnostic headers [...] > For linking, shared objects have their [...] Compiler-agnostic headers that get compiled to compiler-specific calling conventions. If I recall correctly, GCC basically dictates it on Linux. Anyways, I digress. > shared objects have their own versioning to allow backwards-incompatible versions to exist simultaneously (libfoo.so.1, libfoo.so.2). Oooh, that one is fun. Now you have to hope that nothing was altered when that old version got built for that new distro. No feature flag changed, no glibc-introduced functional change. > hey I helpfully upgraded this module! oh and you can't build this at all, your compiler is too old granddad If we look at your initial example again, Cargo followed your project's build instructions exactly and unfortunately pulled in a package that is for some reason incompatible with your current compiler version. To fix this you have the ability to just specify an older version of the crate and carry on. Looking at your C example, well, I described what you might have to do and how much manual effort that can be. Being forced to use a newer compiler can be very tedious. Be it due to bugs, stricter standards adherence or just the fact that you have to do it. In the end, it's not a fair fight comparing dependency management between Rust and C. C loses by all reasonable metrics.