[lldb-dev] Making changes to the SB API

[Zachary Turner via lldb-dev]

For better or worse you need to make a separate function.  An alternative
idea that has been floated is to start making a version 2 SB API and then
eventually deprecate the current API, but probably due to the amount of
work involved and the cost/benefit ratio, nobody's ever really taken point
on it.

On Fri, Jun 8, 2018 at 12:54 PM Leonard Mosescu via lldb-dev <
lldb-dev at 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!
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180608/56f3c747/attachment.html>