SOFA-NG transition

Project timeline

• Github project for SOFA NG
• A GitHub issue was referencing all different PRs, the description of the task and the drafts for SOFA-NG

Components

SOFA-NG introduced new libraries, or more exactly replaces the previous “modules” (e.g. SofaBaseTopology, etc.), as it was deemed difficult for the new users to find a specific component in the code. Moreover, the dependencies between the module were difficult to manage and the sorting was seemingly weird because of unholy hard-dependency in the code.

Since v22.06, a new architecture has been proposed and the SOFA team worked on a compatibility layer aiming at making the transition as smooth as possible for the community. Nevertheless, the compatibility layer might not cover some specifal cases. Do not hesitate to report your technical issues.

We need to handle either the developers of new plugins designing components and simulations; and the “normal” users which only executes simulations. There are 3 layers to manage the compatibility: CMake configure process, at compile-time and at run-time:

• at run-time, highlighting that a component should be loaded from the new library and not the deprecated one (user and dev)
• in the CMake process, informing that the deprecated package should be replaced by which new library (dev only)
• at the compilation time, to warn the user that the path for a chosen header changed in the new architecture (dev only)

CMake

CMake packages for the deprecated modules throw warnings message at the configuration time and redirect to the new ones. Effectively, it does :

find_package(new_package1)
find_package(new_package2)
...
target_link_library(oldmodule new_package1 new_package2)

and it creates an empty shell of a project, dedicated to route the new includes and the new library (.lib, .so) to the new packages.

Compilation

One big package called Sofa.Component.Compat contains all the previous headers (with the previous paths), which merely redirects to the new paths and, if the case occurs, creates an alias of the component into the previous namespace.

This is the most problematic case and where the compatibility is most likely to fail:

• C++ does not allow specialization of templated classes with aliases
• forward declaration in dev files will fail as well, as it is not possible to declare twice a class (first created by the alias and then by the forward declaration, or vice-versa)
• if one did not use explicitly the include of a header but was relying on the other file (e.g using PointSetTopologyContainer but was including TriangleSetTopologyContainer, which is using PointSetTopologyContainer), the compilation will fail.

Obviously, if the move did not imply a change of namespace, the transition is much smoother (for example, with Controller from Sofa.Component.Controller)

Run-time

When a user loads a deprecated module in its scene (either by using RequiredPlugin or by manually loading it), the loading process will display a warning, advising to load the new modules, and then will load automatically the new one. This will allow the scene to still load, even if only the deprecated module was set.

Mapping deprecated modules ↔︎ new libraries

SofaBase

SofaCommon

SofaGeneral

SofaMisc

Plugins

Collection

Framework

SOFA-NG induced also a cleaning in the framework of SOFA. All parts of the framework have been renamed to reflect the same pattern started with Sofa.Component. For example, SofaSimulationGraph becomes Sofa.Simulation.Graph.

The list of the differents packages which are considered as part of the framework is:

Report technical issues

In case you face any technical difficulty in the transition, please report it using our GitHub Discussion forum.