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 <bc...@apache.org> wrote: > 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 to branch. > > -Bryan > > > > > On May 23, 2018, at 2:20 PM, Jason Kenny <jke...@oath.com.INVALID> > 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 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 > >> > >> > >
