Alternative way to structure the code files

Every time I check automatic code changes by clang tidy I have the feeling the code structure of PCL has more disadvantages than benefits:

Current file structure

File structure

pcl/<module>/include/pcl/<module>/impl/<file>.hpp
pcl/<module>/include/pcl/<module>/<file>.h
pcl/<module>/src/<file>.cpp

CMake structure

set(srcs
  src/<file>.cpp
)

set(incs
  "include/pcl/${SUBSYS_NAME}/<file>.h"
)

set(impl_incs
  "include/pcl/${SUBSYS_NAME}/impl/<file>.hpp"
)

Advantages:

• You can copy the whole directory to install directory
• You can easily skip whole directories if you have private headers

Disadvantages

• You have multiple list in CMake
• If you review sth. changes to header file and related source file are sticking not together.

Example where you can see it

Local git tool:

GitHub:

Alternatively file structure

File structure

pcl/<module>/<file>.cpp
pcl/<module>/<file>.h
pcl/<module>/<file>.hpp

CMake structure

set(srcs
  <file>.cpp
  <file>.h
  <file>.hpp
)

Advantages:

• Corresponding files stick together => easier to understand a diff & easier to switch between files without IDE
• Simplify CMake code

(Dis)advantages

• You need a schema to differ private header files from other, e.g. <file>_priv.h to say this file should not be copied via install target by CMake (advantage by this: It is always fast to see it this is a public or private header)

Last file structure is e.g. used by Qt as fast I saw until now. We have a similar code structure in our project and it is really always a pain in the ass to switch between files or review sth. here ;-)

Hint: In case you agree I would see it as long term issue, as we should then discuss when to apply this changes, as a lot of PRs will get broken (expect Git & Github manages to follow renaming of files as we don't need to touch source files)

Start by reviewing the module paths under include/pcl/, include/pcl//impl, and src, along with the related CMake srcs, incs, and impl_incs lists. Define the migration scope and public/private-header criteria, then confirm that the proposed layout and install behavior can be applied without leaving the project in a broken state.