>>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 have. We have to start someplace, and honestly this is a good first step. Jason On Wed, May 23, 2018 at 3:20 PM, Leif Hedstrom <zw...@apache.org> wrote: > > > > On May 23, 2018, at 1:38 PM, Alan Carroll <solidwallofc...@oath.com.INVALID> > 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 use them. If we expect core plugins to server as examples, > > facilities they use should be also available to non-core plugins. This PR > > is a demonstration and only provides TextView.h to plugins. If the setup > is > > acceptable I (or others) will move other headers for plugin availability > > (e.g. BufferWriter, MemArena, MemSpan, ink_inet.h as a first wave). We > > don't need to get all of these for 8.0 but I would like to get the > > framework in which they can be moved set up. > > > Commented on the PR, but tldr: > > 1) I don’t like the “src” top level directory, that implies that all > source is there (which is clearly not the case) > > 2) Lets start using the Makefile.inc pattern for new things, as in e.g. > plugins. > > 3) Bigger question: How does the existing CPP API public include files fit > into this? Feels like there should be one place for all C++ includes (and > one for all C-level includes). > > > Cheers, > > — Leif > >
