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
wrote:
> That's a bit much. Let me take a look at how it could be refactored to
> reduce the depend
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 wrote:
>
>
> > On Mar 27, 2018, at 4:54 PM, Walt Karas wrote:
> >
> > Is there any ways to ensure ABI compatibility other than to compile
> > the plugin
> On Mar 27, 2018, at 4:54 PM, Walt Karas 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 in
Is there any ways to ensure ABI compatibility other than to compile
the plugin and the core with the same compiler and same options?
On Tue, Mar 27, 2018 at 5:51 PM, Leif Hedstrom wrote:
>
>
>> On Mar 27, 2018, at 4:23 PM, Walt Karas wrote:
>>
>> With some tricky symbolic links, I could probably
> On Mar 27, 2018, at 4:23 PM, Walt Karas 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 a
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.
On Tue, Mar 27, 2018 at 5:15 PM, Derek Dagit wrote:
> One reason thi
One reason this could be scary is that should we change any of these
headers going forward, it could mean a backward-incompatible release for
ATS.
In-place upgrades may not be possible for administrators without
recompiling their plugins.
On Tue, Mar 27, 2018 at 5:08 PM, Walt Karas wrote:
> If
If we make BufferWriter.h available to C++ plugins, we would also have
to make all of these header files available to plugins:
MemSpan.h
ink_assert.h
BufferWriterForward.h
ink_apidefs.h
ink_error.h
ink_std_compat.h
ink_platform.h
ink_config.h
ink_autoconf.h
Scary right? Or not so much?
