4 ms·

> To reiterate for the umpteenth time: many C and C++ libraries come with compile-time flags that totally change the nature of the resulting library. It is not

by duped 5y ago

> To reiterate for the umpteenth time: many C and C++ libraries come with compile-time flags that totally change the nature of the resulting library. It is not possible to refer to a "canonical" version of the library the way you could with something for Java, Python, JS etc. That just iterates GP's point: C/C++ dependency management is abysmal, but it's "hard" because the languages themselves do not have the capability to express the required metadata in any standard way. As an example, the first time I tried to compile Ardour took me several hours finding and installing the right dependencies for my distro. PL designers have learned from these mistakes, it's not worth defending them or accepting that it is the way the world should be...

PaulDavisThe1st 5y ago
> but it's "hard" because the languages themselves do not have the capability to express the required metadata in any standard way. Of course the languages don't. It's not a part of the language. If I build libfoo with -Dexclude_feature_bar which just drops 2 source modules from the library build, how can the language express that? On Debian, you get the Ardour dependencies like this: apt-get build-dep ardour6 If your distro makes it hard than that, that's a distro problem. Of course, the libraries Debian or any other distro will install when you do that are not the ones we use to build Ardour, because we have patches for several libraries that will never be accepted upstream but are necessary/useful/important for Ardour. You can't express that with the language either.
- spoiler 5y ago
  I think you and the previous poster are talking about the same thing. I think they are pointing out that there's no way to express (I guess there is via macros, but it's a workaround) this, whereas it's innate to Cargo and Rust.
  - PaulDavisThe1st 5y ago
    It cannot be innate to any language because I may wish to link libraries written in other languages. You cannot use Cargo or Rust to describe how a C or C++ library was compiled and linked.
- duped 5y ago
  I don't see why it can't be a part of the language, since the language implementation requires that the notion of compilation configuration exists and even C/C++ has a specific language construct to check for it (through the preprocessor). > If I build libfoo with -Dexclude_feature_bar which just drops 2 source modules from the library build, how can the language express that? By expressing within the language that the library can be configured with an optional `exclude_feature_bar` flag. Then downstream dependencies can express they require importing libfoo configured with exclude_feature_bar. At least in Rust where the compilation unit is a crate, crates must express what their compile options are, and dependents express that they require specific compile options from their dependencies. You could argue this isn't a property of the language, but I would argue it is since it's so tightly coupled to the language implementation (despite living in a config file, that file is required to build anything) Since C and C++ eschew this fundamental requirement of packaging software and pass the buck to the library authors to figure out a way to describe available configuration options, there's no standard way to do this, and dependency management becomes quite difficult. That doesn't mean that other language authors can't solve the problem. And it plays into what the original comment said, which is that managing dependencies in C/C++ is abysmal.
  - PaulDavisThe1st 5y ago
    So let's take one of my canonical examples. libfftw (Fastest Fourier Transform in the West) can be built with at least the two following critical options: 1. use double or float for computation 2. thread-safe or not The result is 4 possible versions of libfftw: double + thread-unsafe float + thread-unsafe double + thread-safe float + thread-safe What aspects of rust's crate design will allow me, developer of an application that uses libfftw, to define which of these I want to use? How many crates will I have installed in order to switch between any of them?
    - duped 5y ago
      So we're in agreement that the C and C++ languages cannot express compilation requirements. I'm saying this is a reason why dependency management in these languages is hard. Any language depending on C/C++ will not be able to magically fix the lack of module semantics, just like they can't magically fix use-after-frees across FFI. However, if fftw was wrapped in a Rust crate, the manifest can express those using features in the Cargo.toml file [1] which can be read in a build.rs[2] script which would provide the proper configurations to libfftw at build time for all dependents that specify which options it needs. In this model you won't need more than one crate installed for libfftw, since the crate expresses everything needed. Crates are not static collections of object files like C/C++ libraries. [1] https://doc.rust-lang.org/cargo/reference/features.html https://doc.rust-lang.org/cargo/reference/features.html [2] https://doc.rust-lang.org/cargo/reference/build-scripts.html https://doc.rust-lang.org/cargo/reference/build-scripts.html

by duped 5y ago

PaulDavisThe1st 5y ago

> but it's "hard" because the languages themselves do not have the capability to express the required metadata in any standard way. Of course the languages don't. It's not a part of the language. If I build libfoo with -Dexclude_feature_bar which just drops 2 source modules from the library build, how can the language express that? On Debian, you get the Ardour dependencies like this: apt-get build-dep ardour6 If your distro makes it hard than that, that's a distro problem. Of course, the libraries Debian or any other distro will install when you do that are not the ones we use to build Ardour, because we have patches for several libraries that will never be accepted upstream but are necessary/useful/important for Ardour. You can't express that with the language either.

spoiler 5y ago
I think you and the previous poster are talking about the same thing. I think they are pointing out that there's no way to express (I guess there is via macros, but it's a workaround) this, whereas it's innate to Cargo and Rust.
- PaulDavisThe1st 5y ago
  It cannot be innate to any language because I may wish to link libraries written in other languages. You cannot use Cargo or Rust to describe how a C or C++ library was compiled and linked.
duped 5y ago
I don't see why it can't be a part of the language, since the language implementation requires that the notion of compilation configuration exists and even C/C++ has a specific language construct to check for it (through the preprocessor). > If I build libfoo with -Dexclude_feature_bar which just drops 2 source modules from the library build, how can the language express that? By expressing within the language that the library can be configured with an optional `exclude_feature_bar` flag. Then downstream dependencies can express they require importing libfoo configured with exclude_feature_bar. At least in Rust where the compilation unit is a crate, crates must express what their compile options are, and dependents express that they require specific compile options from their dependencies. You could argue this isn't a property of the language, but I would argue it is since it's so tightly coupled to the language implementation (despite living in a config file, that file is required to build anything) Since C and C++ eschew this fundamental requirement of packaging software and pass the buck to the library authors to figure out a way to describe available configuration options, there's no standard way to do this, and dependency management becomes quite difficult. That doesn't mean that other language authors can't solve the problem. And it plays into what the original comment said, which is that managing dependencies in C/C++ is abysmal.
- PaulDavisThe1st 5y ago
  So let's take one of my canonical examples. libfftw (Fastest Fourier Transform in the West) can be built with at least the two following critical options: 1. use double or float for computation 2. thread-safe or not The result is 4 possible versions of libfftw: double + thread-unsafe float + thread-unsafe double + thread-safe float + thread-safe What aspects of rust's crate design will allow me, developer of an application that uses libfftw, to define which of these I want to use? How many crates will I have installed in order to switch between any of them?
  - duped 5y ago
    So we're in agreement that the C and C++ languages cannot express compilation requirements. I'm saying this is a reason why dependency management in these languages is hard. Any language depending on C/C++ will not be able to magically fix the lack of module semantics, just like they can't magically fix use-after-frees across FFI. However, if fftw was wrapped in a Rust crate, the manifest can express those using features in the Cargo.toml file [1] which can be read in a build.rs[2] script which would provide the proper configurations to libfftw at build time for all dependents that specify which options it needs. In this model you won't need more than one crate installed for libfftw, since the crate expresses everything needed. Crates are not static collections of object files like C/C++ libraries. [1] https://doc.rust-lang.org/cargo/reference/features.html https://doc.rust-lang.org/cargo/reference/features.html [2] https://doc.rust-lang.org/cargo/reference/build-scripts.html https://doc.rust-lang.org/cargo/reference/build-scripts.html