On Mon, Jan 2, 2023 at 10:52 PM Demi Marie Obenour <demiobenour@xxxxxxxxx> wrote: > > On 1/2/23 22:30, Kevin Kofler via devel wrote: > > Fabio Valentini wrote: > >> - incompatible compile-time options (i.e. resulting in conditional > >> compilation): different packages depend on crates with different sets > >> of features enabled, sometimes with conflicting options. Even with a > >> stable ABI, you'd need to build crates for all necessary combinations > >> of configurations, and that matrix quickly explodes (i.e. usually > >> exponentially - 2^n builds for for n independent flags). This is a > >> deal-breaker for shared libraries in most cases, and also can't be > >> solved by using a different compiler. (Unless you want to figure out > >> *which* combinations to build, and *only* build these.) > > > > Let me try formulating my criticism more constructively (since my previous > > reply failed both at being polite and at getting my point through, sorry > > again for that): > > > > I am really surprised to read above that Rust apparently allows applications > > to pick the flag with which the libraries they depend on are compiled. I > > really have to wonder why anyone would think that allowing that would be a > > good idea, but then again I guess I know the answer: Whoever added this > > feature was so set in a mindset where everything is compiled on demand and > > statically linked that they figured: why not? > > One of the major uses is to allow code that requires a particular > dependency to be disabled when that dependency is not available. > In particular, Rust targets platforms (such as OS kernels and embedded > systems) where the standard library is not available. This would be > extremely difficult without Cargo features. > platforms != features. That said, some crates do support "nostd" as a feature flag, others don't. It depends. > > And if you are in that mindset, that actually sounds like a reasonable call > > to make. Source-based software distributions do have the advantage of > > offering this kind of flexibility on demand, see also the USE flags in > > Gentoo. Those are in fact one of the main reasons some people decide to > > compile an entire GNU/Linux distribution from source (and hence pick a > > distribution such as Gentoo) to begin with. Likewise, the Rust way of > > compiling dependencies on demand allows applications to make this kind of > > settings for them. > > > > Still, I can see several issues with that approach, e.g., what if an > > application depends on two libraries A and B that both depend on library C, > > but with conflicting flags? > > Last I checked, Cargo features are additive, so the answer is that > C will be compiled with the union of all flags used by A and B. > > > But the main issue is that, as you point out, it > > makes binary distribution of shared libraries highly impractical. That is > > why I think this was a short-sighted design decision. > > Cargo features are supposed to be additive, so one can sometimes ship > a single package with the union of all features used by its reverse > dependencies. This must be handled on a case-by-case basis, though. Even if it wasn't, building a library in various feature modes would be possible. Cargo would just need to know which binary object to select to link with, which I imagine it would learn how to do if someone cared about shared libraries in Rust upstream. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
