> On Mar 27, 2018, at 4:54 PM, Walt Karas <wka...@oath.com.INVALID> wrote: > > Is there any ways to ensure ABI compatibility other than to compile > the plugin and the core with the same compiler and same options?
Well, we can’t change things such as orders within enum / structs in the core for an example of an ABI incompatible change. IF those enum’s / structs are exposed. We went through a refactoring for this exact reason, to make sure that the core and plugins use the same versions of such things, that’s why we have #include <ts/apidefs.h> now. API incompatibilities are of course easier to detect / notice, but I suspect the concern raised here would be that we break something in those many include files, that changes the ABI for the plugins. I can’t give an example, but something to look at. Cheers, — leif > > On Tue, Mar 27, 2018 at 5:51 PM, Leif Hedstrom <zw...@apache.org> wrote: >> >> >>> On Mar 27, 2018, at 4:23 PM, Walt Karas <wka...@oath.com.INVALID> wrote: >>> >>> With some tricky symbolic links, I could probably arrive at a solution >>> where these header would be exported (to plugins) in include/detail or >>> something, not include/ts, so plugins writers would know not to >>> include them directly. >> >> >> >> It also means that whatever APIs you *do* expose to plugins from hereon must >> be API and ABI compatible within the major releases. >> >> — leif >>
