Hi everyone, 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 code2) 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 code3)
untangle the dependency mess of everything needing everything else4)
untangle what modules are being built5) Make it easier for
everyone to understand the Architecture and design6) Make it easier
to improve/cleanup the testing systems7) 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 awayPhase 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 /srcIn 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,
InfraModules in API can depend on modules in Core, InfraModules in Core can
depend on modules in Core, InfraModules 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 beSrc/ 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
