On Mon, Aug 21, 2017 at 12:23 PM, Christian Stadelmann
> 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 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!