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 >> >>
