OK, I took a stab at one approach to this issue: https://github.com/apache/trafficserver/pull/3361
But the ABI vs. API issue is not addressed by this. On Tue, Mar 27, 2018 at 8:45 PM, Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > 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 >> >> >> >>
