Hello,
Please I am between the devil and deep blue see, I need your urgent response
to my message.
Wilson Criag
wilsoncr...@aol.com
Having both external and internal APIs in libtsutil also cause issues for ABI
compatibility testing. Existing tools use the .so to test for ABI
compatibility.
-Bryan
> On May 24, 2018, at 11:08 AM, Alan Carroll
> wrote:
>
> Bryan;
>
> Yes, plugins have no need to explicitly link with lib
Hello,
Please I am between the devil and deep blue see, I need your urgent response
to my message.
Wilson Criag
wilsoncr...@aol.com
Bryan;
Yes, plugins have no need to explicitly link with libtsutil. Therefore it
is clearer if headers for code in that library are separated from headers
where linking with a library is required.
" tsxs and our build tree should add libtscpp.so as a library to link with
when using c++ automatica
Hello,
Please I am between the devil and deep blue see, I need your urgent response
to my message.
Wilson Criag
wilsoncr...@aol.com
Hello,
Please I am between the devil and deep blue see, I need your urgent response
to my message.
Wilson Criag
wilsoncr...@aol.com
Plugins shouldn’t link with libtsutil to begin with and is not required since
traffic_server already loads the .so and we don’t check if the symbols exist
for plugins. tsxs and our build tree should add libtscpp.so as a library to
link with when using c++ automatically.
Also, we should also sp
Hello,
Please I am between the devil and deep blue see, I need your urgent response
to my message.
Wilson Criag
wilsoncr...@aol.com
Some of the non-API code would be helpful to have available to plugins,
like URL parsing. (That's not to say headers for such things ought to be
combined with API headers.)
On Thu, May 24, 2018 at 11:11 AM, Alan Carroll <
solidwallofc...@oath.com.invalid> wrote:
> To paraphrase, I'm extremely ne
Hello,
Please I am between the devil and deep blue see, I need your urgent response
to my message.
Wilson Criag
wilsoncr...@aol.com
To paraphrase, I'm extremely negative on combining non-API related utility
headers with TS API headers. They're really quite different and that's
something users (such as me) writing plugins would care about. I would
greatly appreciate them being distinct. Separating API from utility
mechanisms is
It would be best to combine include/tscpp and include/tsutil into one directory
(include/tscpp). External users writing plugins really don’t care about the
dependency distinction between them.
This would mean that would would need to move the files from the lib/ts
directory over to the lib/cpp
Hello,
Please I am between the devil and deep blue see, I need your urgent response
to my message.
Wilson Criag
wilsoncr...@aol.com
Based on feedback here, on IRC, and on the PR, the changes have been
updated.
Exported headers have been moved to the top level 'include' directory.
include/ts -> C API headers.
include/tscpp -> C++ API headers.
include/tsutil -> C++ utility headers.
The same directories are used for the install
14 matches
Mail list logo
