A few questions about SWIG and interface compatibility

First, do we require a minimum version of SWIG? I think the answer to this is currently no. My next question is whether we can require 3.0? It was released close to a year ago, so it should be fairly stable. SWIG 3.0 contains some bugfixes that are useful for generating correct wrappers on Windows, especially with typedefs.

My second question is about our interface guarantees. Are we guaranteeing interface compatibility at the C++ level, or only at the wrapped level? i.e. is it ok to change the signature of a C++ method as long as SWIG can ultimately generate a wrapper that behaves identically?

First, do we require a minimum version of SWIG? I think the answer to this is currently no. My next question is whether we can require 3.0? It was released close to a year ago, so it should be fairly stable. SWIG 3.0 contains some bugfixes that are useful for generating correct wrappers on Windows, especially with typedefs.

My second question is about our interface guarantees. Are we guaranteeing interface compatibility at the C++ level, or only at the wrapped level? i.e. is it ok to change the signature of a C++ method as long as SWIG can ultimately generate a wrapper that behaves identically?

At the C++ level. We have clients (e.g. Xcode) that use the C++ API's directly.

Jim

Thanks. Is there a timeline or roadmap for starting to plan Public API v2.0 (which, if my recollection is correct, will allow us to make breaking changes)?

We could add the new API in a new "lldb2" namespace to try it out the new API 2.0 which would be available through python as lldb2.*. So the LLDB shared library would vend both the 1.0 API via the "lldb" namespace and the new API 2.0 through the "lldb2" namespace.

So we don't need to necessarily wait to start in on it. We will need to do thorough review as we come up with it...

Greg

Thanks, that’s a good idea. I don’t plan to start thinking about this soon btw, mostly just curious so I have a mental roadmap.

Do you have any thoughts on specifying the minimum required SWIG version as 3.0?

We don't do that if it is GPLv3. We are stuck with what we have currently:

% swig -version
SWIG Version 1.3.40