Current progress in OCCT refactoring project

Hello,

This year we are going to concentrate first on a task which perhaps is the longest-pending one in OCCT development - overall refactoring of the code and build system, getting rid of WOK and CDL.

This change will form a basis of the next OCCT version, 7.0.

We have updated the project page describing in more details the planned actions. In this thread I would like to describe the current state of this effort.

1. Elimination of generic classes (see issue #24487 and its children):
   - ~130 unused generic classes are removed
   - ~70 generic classes are converted to "normal" ones
   - conversion of TCollection instantiations to templates is in progress (see #24750 and children)
   - a few other generic and generic-like classes are being treated

   At the end we expect that about 120 generic classes will remain in OCCT 7.0 (compare to ~450 in OCCT 6.3.1).

2. STL-compliant iterators are added in OCCT collection classes (see #24831), which makes it possible to use them in STL algorithms. This change is being reviewed / tested now (also performance is to be checked).
3. Implementation of Handles and type system is in progress (see see #24023). The solution currently being prototyped consists of replacing macro definitions of Handle classes and OCCT type system by C++ templates.

   This will eliminate need to use macros for definition of Handle classes (even if we are still going to keep macros Handle() and STANDARD_TYPE() defined for compatibility with existing code).

   There will be however some requirement to classes that inherit Transient - they will have to declare their base type in this hierarchy by typedef.

   For use of OCCT legacy type system, the class will have to define method DynamicType() returning Handle(Standard_Type). The macro DEFINE_STANDARD_RTTI defining this method will be kept; it will also define base type of the class, thus it will be sufficient to add this macro to the class definition to have complete support of OCCT handles and types.

4. Revision of the build system is started from analysis of experience of SALOME project and possible improvements of existing CMake scripts in OCCT.
   Here the open question is how to organize header files. For development, it is natural to place header files aside with the corresponding source, e.g. gp_Pnt.hxx will be put to src/gp. However, for using header files the existing (and common) approach is to collect all headers in one subfolder, inc.

   We consider three alternative approaches:

   a) Copy header files to inc directory before building. This corresponds to current approach we have with WOK, and it is not convenient since it requires additional step before build. More, duplication of header files often leads to confusions in development when the file you start editing after e.g. compiler warning message turns to be not real source but a copy in inc folder.

   b) Create "proxy" files in inc folder, redirecting to source, in development environment, and replace them by actual headers on install. This is approach used by Qt project. It also requires additional build step and introduces extra level of indirection, but makes less confusions.

   c) Consume headers directly from src folder. This will require changes in client code (replacing e.g. "gp.hxx" by "gp/gp.hxx" in \#include statements), though this sort of changes can be easily automated. With this approach we do not need extra build step, while installation procedure will have to copy header files.

   Currently we consider approach (c) preferable as it is most simple and straightforward one.

5. Tool for upgrading existing code based on OCCT for accounting of the changes made in this project is developed in parallel to such changes (see #24816). Besides this upgrade, this tool will provide also additional consistency checks and checks of compliance with the coding rules.

Please feel free to comment and contribute.

Andrey