Can you talk more about the alternative build system? This is one that I don't think we need to change really, but I am open to the idea and want to understand it better.
Thanks. On Tue, Jan 26, 2016 at 12:11 PM Jason Kenny <jke...@yahoo-inc.com.invalid> wrote: > Thank you for your input. > Items like P_ I_ and other general code clean up I was hoping to do in a > different phase. many of us could easy make a massive diff with all most of > the issues corrected. However this diff would make most of our heads > explode. I think that it is very important to make each phase small and > directed to help allow movement in a good direction. I know personally > there are a number of item in the code itself I would like to address as > well as fixing up the testing system. I believe that getting the relayout > down first will help all other efforts as this will allow for clearer and > more understandable diffs when we address issues such as fixing up the P_ > I_ stuff or adding new tests, etc. > Personally I would like to address: > 1) provide an alternative build system to the current auto-tools2) clean > up the testing. This is not small amount of work, and I would hope that I > would be able to provide a better subsystem that we all can use. One that > is more accessible and useful than what we have at the moment.3) some stuff > in the code like the memory allocator and threaded event system, which i > have a background in doing > But before this can be done correctly I really believe we have to clean up > the source layout. I want to get this done first and as quick as possible > to reduce the pain caused by the source moves that would upset existing ( > and future) pull requests. > Jason > > > From: Phil Sorber <sor...@apache.org> > To: dev@trafficserver.apache.org; Jason Kenny <jke...@yahoo-inc.com> > Sent: Tuesday, January 26, 2016 12:32 PM > Subject: Re: Proposal for how to update source code layout. > > This seems generally good to me. I welcome a more modern structure. I also > prefer the first layout you mentioned, but it may be necessary to do the > second layout and then move to the first. That might make others more > comfortable. I personally see a lot of value in what you describe, but I > know others may still need more convincing and specific details. > > Also, you didn't mention some things specifically, but I assume we are > doing away with things like the P_ and I_ in the header files? We should > also make it so that the docs don't get needlessly built. I'm sure there > are a bunch of other things, but those are the ones that come to mind. > Another thing I think we need to be careful with is people who have long > lived feature branches. They really need to be rebasing against master a > lot or perhaps just pushing their changes upstream quicker. > Be prepared for a lot of bike shedding. This is likely to be a long slow > process as we address the merits of each change and how it fits into the > bigger picture and what are the pros and cons of each. > > On Mon, Jan 25, 2016 at 3:43 PM Jason Kenny <jke...@yahoo-inc.com.invalid> > wrote: > > > > > Hi everyone, > > Second try as the first attempt seems to be a blob of unformated text. > I want to see about moving forward on the source clean up I believe we > all agreed to the last ATS summate. What I would like to get general > agreement on what I plan to do to the source layout so it is clear why and > where everything will go before I start making lots of small pull requests > pulling moving source and cleaning up the build. > First what are the goals? > Cleaning up the source to will proved: > 1) Better clarity on where to put new code. > a. Making it easier to refactor code > b. Making it easier for others to change code > 2) simplify the build code > a. making it easier to use other build system if desired > b. making it easier for others to add or remove code > 3) untangle the dependency mess of everything needing > everything else > 4) untangle what modules are being built > 5) Make it easier for everyone to understand the Architecture > and design > 6) Make it easier to improve/cleanup the testing systems > 7) Allow a better setup to hopefully avoid any major source > layout refactors for a long time > > I want to clarify that this was generally agreed on by everyone at the ATS > summate. We want to avoid this unless needed. I believe people feel overall > this would be a good thing, but I want to make sure that I define the > envisioned layout we will move to so we all understand the where we are > going before doing this. Ideally we will want to do the major part of this > work as fast as we can to minimize the pain as much as possible. > > Before I go into the layout, I want to talk about process. I plan to break > this up into phases. > Phase 1 – move source to new location and any header cleanup that might be > needed. Once this phase is done we will still have dependency issues to > deal with, however it should be clearer on what is wrong, and some of the > dependency issues should just go away > Phase 2 – refactor source to deal with dependency issues, to clean up mega > source files and start some cleanup of the tests. This will make it easier > to find objects and make changes in a way to that should not make compiling > more complex. It should also make it easier to understand and learn the > code. > > The hope I have is that will help minimize the size of any given diff. > Will have more diff overall, but these will all be small and to the point. > > Now let talk about layout (finally :-) ) > > The current layout has something like this at the top layer > /build > /ci > /cmd > /contrib > /doc > /example > /iocore > /lib > /mgmt > /plugins > /proxy > /rc > /tools > > Source needed to build Traffics Server exits in /proxy, /mgmt, /lib, /cmd > and /iocore. These directories also have tests in them as well. In some > case the tests and the source is mixed. I would like to change the top > level to look like this instead: > /build > /ci > /contrib > /doc > /plugins > /rc > /src > /tests > /tools > > We move the code in /examples, /proxy, /mgmt, /lib, /cmd and /iocore. The > addition of a src and test directory will help clarify what is the source > to than traffic server application vs that of being a test or something > else, such as an example or an optional plug-in. The code for /examples > moves under /plugins, everything else under /src > In the /src directory we would have a layout like this: > src/ > api/ > c/ > cpp/ > config/ > cmd/ > … > core/ > … > Infra/ > … > > Details: > api – contains all the API code for a given language. Any new language API > would be added here under a directory correctly names for the language. > config- Contains the default config file to run traffic server. > cmd – Contains the code for each program in a name directory. > core – Contains the main modules to build different programs under the > cmd/ directory. Modules under here depend on modules in Infra, or other > modules in Core itself. Code here should be more Traffic server specific > modules. > infra – Contains the support modules. Modules in here are leaf modules, > may be reusable. If the module is not a leaf module it can only depend on > code in Infra and should be generally reusable. > > Dependencies: > Modules should not depend on other modules that depend on them. The only > expectations would be header only dependencies that don’t require link time > circular dependencies. > Modules in CMD can depend on modules in API, Core, Infra > Modules in API can depend on modules in Core, Infra > Modules in Core can depend on modules in Core, Infra > Modules in Infra can depend on modules in Infra > > Header Patterns: > The general include pattern will be changed to #include <module/header.h> > for modules depending in on other headers. Files depending on headers in > the same module will be in the form of #include “header.h” > > An alternative to this layout would be > Src/ > api/ > c/ > cpp/ > config/ > mgmt/ > proxy/ > … > iocore/ > … > lib/ > … > > The main difference is here is that it look like it did before. However > much of the code in proxy or mgmt would be moved to lib as it is a leaf > component, or the code would be moved in to a directory based on module it > would be used to generate, vs having lots of modules in a given directory. > Because of this I felt it might be easier to use the first layout as it > contains a simpler set of logic on where code goes. > Given that we agree with the layout. The process will be to move > components that are on the leaf first and slowly move up the chain. Each > commit will be on component at a time, with changes to the source files > #include and any make file changes to allow the code to build as expected. > After a component is moved that changes that break up source can happen, > where the commit will include the makefile changes and the split source any > header file changes need to support the split. > > I think that is it. I will deal with “tests” after main source changes. > > Any question or concerns? > > Jason > > > >
