Following the remarks we got from the SOFA conda package PR on conda-forge (https://github.com/conda-forge/staged-recipes/pull/23085), we have some problems regarding some external libraries that are embedded in SOFA code.
Here is a try to sum up all of these embedded libraries:
Lib name
Type
Location in code
License
Status
difflib
header-only
extlibs
MIT
OK
json nlohmann
header-only
extlibs
MIT (should be in a separate file)
OK. Fixed in #4272
stb
header-only
extlibs
MIT
OK
TinyXML
static
extlibs
zlib (should be in a separate file)
Externalize tinyxml dependency: #4240 (waiting for merge)
miniFlowVR
static
applications/plugins/SofaDistanceGrid/extlibs
LGPL (version ?) (should be in a separate file)
Not built by default. TODO: plugin to be externalized (#1442 )
newmat
static
applications/plugins/SofaNewmat/extlibs
type inconnu
Not built by default. TODO: plugin to be externalized (#1442 )
CImg
header-only
applications/plugins/CImgPlugin/extlibs
CeCILL-C / CeCILL
OK
csparse
static
Sofa/Component/LinearSolver/Direct/extlibs
no license file
Plugin to be externalized. WIP : #4258
metis
static
Sofa/Component/LinearSolver/Direct/extlibs
Apache v2
Externalize metis dependency : #4266 (waiting for merge)
gtest
shared
Sofa/framework/Testing/extlibs
BSD-3-Clause
Externalize ?
cxxopts
header-only
Sofa/GUI/Common (fetched from GitHub)
MIT
Add to possibility to use external dependency and prevent from fetching: Fixed in #4273
libQGLViewer
shared
Sofa/GUI/Qt
GPL
Find or use embedded code (find module being fixed in #4290)
The actions we should take to make our code compatible for the conda package on conda-forge are:
Fix the missing licenses files (points in bold)
Avoid all static libraries.
For point 2, we are not concerned by miniFlowVR and newmat, as we do not compile the corresponding plugins for the conda package, at least for now. Before considering any action on these two, do the SofaDistanceGrid and SofaNewmat plugins are still used and planned to be maintained in future releases ?
Regarding other static libs (TinyXML, csparse and metis), could we consider to switch to an external dependency instead ? For TinyXML, the current behavior is to first look for an external package, and fallback to embedded version if unavailable. This looks reasonable at first, but shouldn't we switch to fully externalized versions for maintainability ?
Last point, we were also advised to use external dependency for some header-only libraries, especially when they are already packaged in conda-forge. Could we consider also to use externalized versions for some of these (the ones easily available as external packages), such as json nlohmann and cxxopts ?
extlibs
extlibs
(should be in a separate file)extlibs
extlibs
applications/plugins/SofaDistanceGrid/extlibs
applications/plugins/SofaNewmat/extlibs
applications/plugins/CImgPlugin/extlibs
Sofa/Component/LinearSolver/Direct/extlibs
Sofa/Component/LinearSolver/Direct/extlibs
Sofa/framework/Testing/extlibs
Sofa/GUI/Common (fetched from GitHub)
Sofa/GUI/Qt
The actions we should take to make our code compatible for the conda package on conda-forge are:
For point 2, we are not concerned by miniFlowVR and newmat, as we do not compile the corresponding plugins for the conda package, at least for now. Before considering any action on these two, do the SofaDistanceGrid and SofaNewmat plugins are still used and planned to be maintained in future releases ?
Regarding other static libs (TinyXML, csparse and metis), could we consider to switch to an external dependency instead ? For TinyXML, the current behavior is to first look for an external package, and fallback to embedded version if unavailable. This looks reasonable at first, but shouldn't we switch to fully externalized versions for maintainability ?
Last point, we were also advised to use external dependency for some header-only libraries, especially when they are already packaged in conda-forge. Could we consider also to use externalized versions for some of these (the ones easily available as external packages), such as json nlohmann and cxxopts ?