Ok, I’ll review and deny... I mean approve, tomorrow.
— Leif
> On Jun 16, 2018, at 11:41, Alan Carroll
> wrote:
>
> As noted on the PR, I moved the exported C++ utilities to a separate
> library based on comments from Bryan and Jason last week, and have had no
> further comments. I think it's
As noted on the PR, I moved the exported C++ utilities to a separate
library based on comments from Bryan and Jason last week, and have had no
further comments. I think it's time to commit this PR which I plan to do
Monday.
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
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
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
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
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
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
I gave a talk on this my first summate. Honestly, most people I talk to are
+1 on this.
The only complaint about fixing our layout and refactoring broken code was
that it makes it hard to cherry pick back to older drops. People complain
and hack the build more and more. I want to:
1) simplify the
That's why I only moved one file. What I wanted was to set up the future
framework without disrupting 8.0. If the directory is there we can make
progress over the course of the 8.0
On Wed, May 23, 2018 at 4:56 PM, Bryan Call wrote:
> I don’t see how it solves any problems by moving the code unde
I don’t see how it solves any problems by moving the code under src. However,
this is a common practice in open source projects and I am in favor of it
because it is common practice. This should be discussed before a PR is created
and shouldn’t go into 8.0.0 this late, right before I am going
> On May 23, 2018, at 3:20 PM, Jason Kenny wrote:
>
>>> 1) I don’t like the “src” top level directory, that implies that all
> source is there (which is clearly not the case)
> We cannot move everything at once. We have to do stuff in small steps.
>
> I would really like to get all the source
>>1) I don’t like the “src” top level directory, that implies that all
source is there (which is clearly not the case)
We cannot move everything at once. We have to do stuff in small steps.
I would really like to get all the source under an src/ dir to solve a
number of stupid build problems we h
> On May 23, 2018, at 1:38 PM, Alan Carroll
> wrote:
>
> I have a PR up, 3724, with a first pass at setting up a directory structure
> both in the source tree and the install tree to enable exporting headers
> from what is current lib/ts to the install directory so that non-core
> plugins can
15 matches
Mail list logo
