The size of the shared object files generated by OpenCascade is a problem in at least two regards.
First, for a new platform, the larger the shared object file, the greater the chance of running into bugs in the linking tools on that platform (I have seen link failures for the STEP module under IRIX). A less important part of this issue is that compilation and linking bugs that are encountered in a module require that the expensive linking step be completely redone for each recompile and relink step.
The second problem area has to do with efficiency in the application build with the OpenCascade libraries. If this application uses only a small fraction of the functionality in a module, there is the chance that the dynamic page loading from the shared object file for the module will load mostly unused portions of that library module. If the functions used happen to be widely scattered throughout the shared object file, this problem becomes worse.
Another, less important issue for application developers is the desire to minimize the overall size of the applications that they ship, By breaking the modules into smaller units, the shared object files that actually need to be packaged with the application will use less disk space than the shared object files of the current, large modules.
Of course, the need for smaller modules is most dramatic with the STEP module, but it is also important with the IGES module. At the very least the Reader and Writer portions of STEP and IGES should be placed in separate modules, with common functionality going into yet another module.
Another practical reason for this is the fact that some applications would only need to have a STEP or IGES Reader. Others may only need a STEP or IGES Writer, although this is less likely. Moreover, even for applications that involve both a Reader and Writer of STEP or IGES, these actions would only be performed at widely separated times. Separate shared object libraries would then help the Reader and Writer phases of STEP and IGES to be more efficient.
So the suggestion here is: please break up the large modules of OpenCascade into several submodules in a way that will tend to maximize the efficiency of the shared object files, particularly the loading of pages of these shared object files into memory.
Thanks, Grant Cook