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