Current initialization of the global geometryregister suffers from a
classic 'initialization order fiasco'. Depending on the order the
compilation units are loaded/linked, the initialization of the global
geometryregisterarray is not guaranteed to happen (and indeed often
does not happen) before it is used. This leads to entries being
appended before it's initialized (usually 'suceeding, but potentially
causing memory corruption if the segment at that point isn't zeroed),
initialization then happening halfway through (wiping the initial
entries) and then the last entries being the only ones that show up.
The net effect is either a crash at startup, or several geometry types
seeming to be missing. Eg, step files will oad, but STL files are
just ignored. The bug is actively observed on, eg, Linux.
This patch implements a simple 'initialize at first access' convention
for the array, eliminating the ordering problem.
I've not reviewed the rest of the source for other potential examples
of the fiasco pattern; this fixes only the geometryregister, since
that was actively biting.
move fieldlines code to meshing dir
move visualization function pointers to meshing directory
DLL_HEADER -> NGGUI_API in visualization lib
move soldata.hpp to meshing
update occ, no freetype necessary anymore
Found via `codespell -q 3 -S ./external_dependencies/pybind11 -L alledges,allright,ane,anormal,ans,apoints,ba,boxs,cancle,childs,co-ordinate,co-ordinates,daty,enty,filld,hel,identifyable,ist,linz,lod,ned,nd,selt,statics,suround,thev,thist,thisy,timere,upto,wel`
The CMake export of Interface libraries also exports PRIVATE build
settings, which leads to build errors with non-existing include paths and .lib files for binary distributions.
Use the work-around mentioned here to circumvent this behavior:
https://gitlab.kitware.com/cmake/cmake/-/issues/15415#note_849405
