clayborg added a comment. We have been quite stable on our public API over the years which allows people to create native tools that link against our public API and we don't regress it so things always compile or would actually still run against an older LLDB library.
In D120100#3331209 <https://reviews.llvm.org/D120100#3331209>, @mib wrote: > In D120100#3331141 <https://reviews.llvm.org/D120100#3331141>, @JDevlieghere > wrote: > >> Removing the enum from SBDebugger is an ABI breaking change. I think this >> has been in tree for a while, so if we shipped this like this in the last >> release, we cannot guarantee that this won't break anyone. Can we avoid the >> issue by defining the enum in the interface file? > > Please, correct me if I'm wrong but in my understanding, this is partially > implemented from the ABI standpoint as it's not defined in the SWIG interface > file. Even though it's defined in the C++ liblldb, I don't think it reaches a > bigger audience than the Python `lldb` module. lldb-vscode.cpp links against it, so it is being used. For Swift support, we rely on the fact that an binary like lldb-rpc-server or lldb-vscode can target newer LLDB libraries both from a building against headers perspective and also from a newer executable running with an older LLDB library standpoint. > Defining it in the interface file will increase the maintenance burden so I > think it's reasonable to "break" the ABI in this case. Do you see any > objection @clayborg ? So yes, in order to keep our API stable I object. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D120100/new/ https://reviews.llvm.org/D120100 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
