Thanks. I wasn't sure how well C++ overloading works with SWIG, that's definitely a more ergonomic solution.
On Fri, Jun 8, 2018 at 1:16 PM, Greg Clayton <clayb...@gmail.com> wrote: > > > On Jun 8, 2018, at 12:54 PM, Leonard Mosescu via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > What is the governing philosophy around making changes to the SB API? The > "SB API Coding Rules <http://lldb.llvm.org/SB-api-coding-rules.html>" > page establishes the practices on how to avoid introducing accidental > incompatibility, but what > about the cases where there's a case for intentionally making changes? > > For example, I'd like to make a small change to SBTarget to allow > surfacing errors during LoadCore(): > > SBProcess SBTarget::LoadCore(const char *core_file) > > > And add an explicit out error parameter (in line with SBTarget::Attach(), > Launch(), ...): > > SBProcess SBTarget::LoadCore(const char *core_file*, SBError **&**error*) > > If the rule is to strictly avoid any kind of changes then I'd have to > resort to > a COM-like versioning and introduce a new SBTarget::LoadCore2 (or > LoadCoreEx, ... pick > your poison, I'm not set on any name) while also keeping the existing > LoadCore(). > > Any guidance on this? Thanks! > > > Just add an extra overloaded version of LoadCore. We don't want people's > code to not link and since Apple uses a LLDBRPC.framework that sub-launches > a lldb-rpc-server which can connect to older LLDB.framework binaries, we > can't remove functions. > > Greg > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
