2 ms·

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 langu

by 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

PaulDavisThe1st 5y ago
Yes, we agree that the actual languages named C and C++ cannot express compilation requirements. As far as I can tell, neither does Rust as a language. It just so happens that Rust has (thus far) settled on a single build system (Cargo) which (like most other build systems) has a way to express them (and a very expressive one at that, since it is written using Rust itself). This doesn't seem that different from projects that use build systems that express all their compilation requirements, with the difference that the build system uses a different language (e.g. Python). The crate design you've described works as long as all your dependencies are wrapped in a "crate" of the correct type (in the current case of Rust, a Cargo crate). But is it even close to realistic to imagine that there will be correct "crate-like" encapsulations of every C/C++ library, thus enabling them to be used seamlessly from each language with a "crate-like" system? I don't know, maybe this is genuinely likely, at least for Rust. To me, having to assume that the hundreds of millions of lines of code that already exist must be and will be wrapped in a crate-like system seems like a bad bet, and I'd rather have a build system that doesn't require this to be true for me to use any pre-existing code. The model you are describing for crates seems to also break down for 3rd party non-open-source libraries, where (re)compilation as part of the build process for my own application is not an option. In such cases, it's hard to see how proprietary developers would be content with anything other than "a static collection of object files" for their licensable libraries. But maybe I'm wrong about that too.

by duped 5y ago

PaulDavisThe1st 5y ago

Yes, we agree that the actual languages named C and C++ cannot express compilation requirements. As far as I can tell, neither does Rust as a language. It just so happens that Rust has (thus far) settled on a single build system (Cargo) which (like most other build systems) has a way to express them (and a very expressive one at that, since it is written using Rust itself). This doesn't seem that different from projects that use build systems that express all their compilation requirements, with the difference that the build system uses a different language (e.g. Python). The crate design you've described works as long as all your dependencies are wrapped in a "crate" of the correct type (in the current case of Rust, a Cargo crate). But is it even close to realistic to imagine that there will be correct "crate-like" encapsulations of every C/C++ library, thus enabling them to be used seamlessly from each language with a "crate-like" system? I don't know, maybe this is genuinely likely, at least for Rust. To me, having to assume that the hundreds of millions of lines of code that already exist must be and will be wrapped in a crate-like system seems like a bad bet, and I'd rather have a build system that doesn't require this to be true for me to use any pre-existing code. The model you are describing for crates seems to also break down for 3rd party non-open-source libraries, where (re)compilation as part of the build process for my own application is not an option. In such cases, it's hard to see how proprietary developers would be content with anything other than "a static collection of object files" for their licensable libraries. But maybe I'm wrong about that too.