That's a bit much. Let me take a look at how it could be refactored to reduce the dependencies.
On Tue, Mar 27, 2018 at 6:02 PM, Leif Hedstrom <zw...@apache.org> wrote: > > > > 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 > >> > >
