On Mon, Aug 21, 2017 at 12:23 PM, Christian Stadelmann <genodeftest@xxxxxxxxxxxxxxxxx> wrote: >> On 08/21/2017 04:20 PM, Christian Stadelmann wrote: >> >> I think ABI compatibility is achieved by shipping source code only in >> the -devel packages (similar to what Perl does). > > No, you are writing about API stability. Source code may provide API stability, but no ABI stability. > > ABI stability is about making sure that any public (exported) symbol is generated the same way on every compilation with any compiler version. This affects e.g. the order of fields in structs or the way how parameters are laid out in RAM and registers before a function call happens. This cannot be done by source code but requires compiler work. > > With perl (and other interpreters such as python), API stability (usually) induces ABI stability because the interpreter of any perl package is the same, so it only needs internal ABI stability. > > Java is compiled to some intermediate code with the interpreter providing backwards compatibiliy for previous versions. > > In C++, ABI breaks only happen when the compiler gets updated, which only happens on rawhide or pre-alpha testing phase and is followed by a rebuild. Still you may ship any update to any C++ package without breaking ABI or the need to recompile all dependend packages. Boost is an exception here. > > I have no idea about Ocaml and Go. > The vast majority of rust packages will be piles of source code, just like Go. This reduces the scope of rebuilding for rust core changes to only applications, which right now is no worse than what Go does. Eventually, when we get a stabilized ABI from Rust, we'll transition to dynamic link libraries and handle it like we do for most ecosystems that are compiled. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
