> I’m pretty -1 on having files with the same filenames in different
location. I’m sure that will just break all sort of shit, including my tiny
brain.
I strongly agree with this.
> I’m leaning more towards Chao's proposal of cleaning up the actual mess.
If we want to rename the I_ and P_ files, that’s fine too.
We should figure out why the P_ files are needed. It looks like we don't
need them in many cases.
> We moved some stuff to a generic include directory, such that we can get
away with just one single -I${topdir)/include in the compiles, and then use
#include “some_major_module/P_Stuff.h”.
Looks reasonable. I think I_Stuff.h or Stuff.h instead P_Stuff.h.
In total, using I_/P_Net.h for example, if we really need private header
file by some reason, the change would be like this?
# before
/iocore/net/I_Net.h
/iocore/net/P_Net.h
- include search path : ${topdir)/iocore/net
- #include "P_Net.h" and #include "I_Net.h" are used by everywhere
# after
/include/iocore/net/Net.h
/iocore/net/P_Net.h
- include search path : ${topdir)/include
- #include "P_Net.h" MUST be used only in the iocore/net submodule
- other submodules MUST use #include "iocore/net/Net.h"
- Masaori
On Mon, May 13, 2019 at 11:39 PM Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > On May 13, 2019, at 8:33 AM, Walt Karas <wka...@verizonmedia.com.INVALID>
> wrote:
> >
> > How about an approach using recursively nested modules?
> > - Exported headers for a module are in the module directory.
> > - Private headers and implementation (.cc) files are in a subdirectory
> > named "private".
> > - The submodules of a module are subdirectories of the module directory.
> > - Module source files include their own exported headers with #include
> > "../name.h"
> > - Source files include exported headers of other modules with #include
> > "../../module/name.h", #include "../../../module/name.h", etc. That is
> to
> > say, a headers name, preceded by a module name, preceded by two or more
> > parent directory links (..). So that source files only include the
> header
> > files of modules that directly or indirectly contain them.
>
>
> Can you please make that a little bit more complicated please?
>
> I’m pretty -1 on having files with the same filenames in different
> location. I’m sure that will just break all sort of shit, including my tiny
> brain.
>
> I’m leaning more towards Chao's proposal of cleaning up the actual mess.
> If we want to rename the I_ and P_ files, that’s fine too. We moved some
> stuff to a generic include directory, such that we can get away with just
> one single -I${topdir)/include in the compiles, and then use #include
> “some_major_module/P_Stuff.h”.
>
> Ciao,
>
> — leif
>
> >
> > On Mon, May 13, 2019 at 1:20 AM Chao Xu <ok...@apache.org> wrote:
> >
> >> Hi Masaori,
> >>
> >> The functionality does not change as the file name changes：
> >>
> >> - The P_ files should contain any types and definitions that are
> >> private to the subsystem,
> >> - The public interface should be contained in a I_ prefixed header.
> >>
> >> Confusing private and public definitions will cause the code to have
> >> circular dependencies.
> >>
> >> In order to solve the issue that the P_ files are included from out
> >> side of subsystem, we have 2 choice:
> >>
> >> 1. Pulls related types and definitions from P_ files into I_ files (be
> >> careful to do it).
> >> 2. Do not include that P_ files (figure out why the P_ files is needed).
> >>
> >> If you just don't like the I_ and P_ prefix, you can rename the
> >> filename as you want or put them into different directory, for
> >> example:
> >>
> >> - Puts all those I_ prefix header files into iocore/api/ and keeps all
> >> P_ prefix header files within subsystem directory.
> >> - Compile with `-I iocore/api`
> >>
> >> Thanks.
> >>
> >> - Oknet Xu
> >>
> >> Masaori Koshiba <masa...@apache.org> 于2019年5月13日周一 上午9:57写道：
> >>>
> >>> We have a naming convention for header files, P_ or I_ prefix. Details
> >> are
> >>> described in below.
> >>>
> >>>> # Header files
> >>>> In most subsystems, header files are named with a P_ or I_ prefix. P_
> >>> files should contain
> >>>> any types and definitions that are private to the subsystem, while the
> >>> public interface
> >>>> should be contained in a I_-prefixed header.
> >>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/TS/Coding+Style#CodingStyle-Headerfiles
> >>>
> >>> But this looks obsoleted 1). many subsystem don't follow this rule, 2).
> >>> even if this rule is
> >>> followed, P_ files (subsystem private header files) are included from
> out
> >>> side of subsystem.
> >>> (e.g. P_Net.h, P_EventSystem.h )
> >>>
> >>> The consensus at last summit was we should remove this rule.
> >>>
> >>> If there’re any real use case of subsystem private header files, we can
> >>> move them a directory
> >>> under the subsystem and include them internally.
> >>>
> >>> Any thoughts?
> >>>
> >>> Thanks,
> >>> Masaori
> >>
> >>
> >>
> >> --
> >> - Oknet Xu
> >>
>
>
