On 9/28/21 8:41 AM, Stephen John Smoogen wrote: > On Tue, 28 Sept 2021 at 08:20, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: >> >> On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote: >>> Richard W.M. Jones wrote: >>>> OCaml library code can in principle be dynamically linked, eg: >>>> >>>> $ rpm -ql ocaml-extlib | grep cmxs >>>> /usr/lib64/ocaml/extlib/extLib.cmxs >>>> $ file /usr/lib64/ocaml/extlib/extLib.cmxs >>>> /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64, >>>> version 1 (SYSV), dynamically linked, >>>> BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info, >>>> not stripped >>>> >>>> but upstream doesn't make it possible to ship OCaml binaries this way, >>>> (they would still require rebuilding on every library update) and so >>>> we only ship the DLLs not fully dynamically linked OCaml binaries >>>> (except for the C code). >>> >>> Ah? >>> >>> So what sits in the main packages of libraries (e.g., in ocaml-facile as >>> opposed to ocaml-facile-devel) then? Don't only shared libraries belong in >>> the main package? >> >> The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot >> of sense these days. Ideally we'd put them all in one package. >> >>> So I take back my comment that the OCaml stack is properly packaged. ;-) >>> That sounds like almost as much of a mess as Go and Rust then. >> >> I'd hardly say OCaml packging is a mess. It's much closer to the >> spirit of C packaging than those others. If you have *specific, >> actionable* objections I will listen to them. >> >> > > I think Kevin's comment is meant more towards the way the language > packages itself versus the rpm packaging of the language. Going from > Kevin's comments on languages over the years, a 'good' language should > not require such sort of rebuilding. I believe (though I could be wrong) that *most* natively-compiled languages require cascading rebuilds. The only exceptions I am aware of are C, C++ (excluding templates!), and Swift. Haskell, OCaml, Rust, and Go all require cascading rebuilds; I am not sure about Nim or Zig. Providing a stable ABI requires major tradeoffs in a language implementation. It prevents cross-module inlining and other optimizations, and is incompatible with monomorphized generics (unless one takes the C++ route). Furthermore, ABI stability requires committing to the runtime representation of data types and not changing it, even if these decisions prove to later be suboptimal. Rust in particular has changed the way it represents structs by default to improve packing of members. Furthermore, in at least Rust and Haskell, `1 + 2` is actually a call to a standard library routine. If this is not inlined, performance will be abysmal. Rust generics are basically C++ templates, in that code is generated for them when they are instantiated, so ABI stability would require a commitment to never changing the representation of `Vec` or `HashMap`. That is not a commitment that the Rust project has made yet. Overall, I consider automated cascading rebuilds a far more feasible and realistic path forward. Arch already does cascading rebuilds of its Haskell packages, for example, which shows that it can be done. Sincerely, Demi Marie Obenour (she/her/hers)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
