Packaging solution: (ana)conda

[looo]

do you intend to provide windows anaconda packages?

not at the moment. My goal is to provide packages for linux (ubuntu/ arch) first.

The anaconda compiler uses the system native compiler under the hood. So for Python2.7 that's VC9. We will have hope when Python3 support is integrated. For Python3.5 VC14 (VS2015) is used and all the standard packages should work, once we have a VC14 libpack or create everything with anaconda.

I did not know this. So the latest freecad won't work with python2.7 in windows?
As far as I know, there is no official pyside for python3.5 in windows... So maybe we will have to wait until pyside2 is working and freecad has ported to python3 and qt5...

[sgrogan]

So the latest freecad won't work with python2.7 in windows?

In the lib packs Peterl94 has compiled python2.7 with VC12. This is where the version hassle that ickby was referring to comes from. All of the readily accessible compiled extensions are compiled with VC9 and hence don't work with current Freecad. It should work with 0.16 x86 release FreeCAD as this was compiled with VC9.

[looo]

Currently I am trying to compile the latest source of freecad with occt7. My problem is now with netgen. Netgen is build with cmake: https://anaconda.org/freecad/netgen/6.1 ... _1.tar.bz2. So I don't know if this is a problem with the netgen-cmake or if it is a linking error:

Code: Select all

NETGENPlugin_NETGEN_3D.cpp:(.text+0x2fb9): Nicht definierter Verweis auf `netgen::mparam'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x3052): Nicht definierter Verweis auf `vtable for netgen::NgException'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x333f): Nicht definierter Verweis auf `netgen::multithread'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x33e3): Nicht definierter Verweis auf `netgen::NgException::~NgException()'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x3408): Nicht definierter Verweis auf `netgen::NgException::~NgException()'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x342c): Nicht definierter Verweis auf `netgen::multithread'

Has anyone run into a similar situation?

[sgrogan]

Has anyone run into a similar situation?

I think nglib has to be patched to support OCCT7/SMESH7. wmayer provides the patch for Netgen 5.1 here: viewtopic.php?f=17&p=127000#p126997
I tried to compile the Netgen master branch on Win because it has similar changes but I was unsuccessful, and I'm back to trying with 5.1.
vejmarie also posted a patched branch that was successful on linux Netgen 5.3 I think. I'll find the link.

[looo]

thanks, I have added another patch to the conda build process, but still the same problem with netgen.
This are the patches from vejmarie: https://github.com/looooo/FreeCAD_Conda ... tgen.patch
and here is the new one from wmayer: https://github.com/looooo/FreeCAD_Conda ... ecad.patch

[looo]

cmake choose the wrong headers(system instead of conda). But now I see why you have switched to an older version of netgen .

Code: Select all

anaconda/conda-bld/work/src/3rdParty/salomesmesh/src/NETGENPlugin/NETGENPlugin_NETGEN_2D_ONLY.cpp:478:90: error: invalid initialization of reference of type ‘std::shared_ptr<netgen::Mesh>&’ from expression of type ‘netgen::Mesh*’
err = netgen::OCCGenerateMesh(occgeom, ngMesh, netgen::mparam, startWith, endWith);

[looo]

Had some time to work on conda builds again. It seems the smesh build is working now, but the compilation now stops at the fem-module.
This is the error:

Code: Select all

In file included from ~/anaconda/conda-bld/._1473004468427/work/src/Mod/Fem/App/FemMeshShapeNetgenObject.cpp:45:0:
~/anaconda/conda-bld/._1473004468427/work/src/3rdParty/salomesmesh/inc/NETGENPlugin_Mesher.hxx:40:19: fatal error: nglib.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
src/Mod/Fem/App/CMakeFiles/Fem.dir/build.make:426: die Regel für Ziel „src/Mod/Fem/App/CMakeFiles/Fem.dir/FemMeshShapeNetgenObject.cpp.o“ scheiterte

The nglib headers are in include/netgen/nglib/nglib.h. Is it necessary to tell cmake to include this directory for the fem wb?

[looo]

The compilation is now working. This had to be done for the fem libs (maybe this could be applied to master?)

Code: Select all

diff --git a/src/Mod/Fem/App/CMakeLists.txt b/src/Mod/Fem/App/CMakeLists.txt
index 89989fb..2c129e3 100755
--- a/src/Mod/Fem/App/CMakeLists.txt
+++ b/src/Mod/Fem/App/CMakeLists.txt
@@ -22,6 +22,7 @@ include_directories(
     ${XercesC_INCLUDE_DIRS}
     ${SMESH_INCLUDE_DIR}
     ${VTK_INCLUDE_DIR}
+    ${NETGEN_INCLUDE_DIRS}
 )
 

But I can't mesh with netgen. A mesh object is created, but nothing is displayed on the 3d-view. There is no error message or warning. Netgen does work outside of freecad (with setting NETGENDIR to the dir containing ng.tcl.) Any ideas what is missing?

Can anyone point me to the file (fem or Mesh) where the netgen-mesher is called.

[looo]

a question for the c++ experts:
To get freecad work with the latest netgen I had to introduce things like this:

Code: Select all

#if NETGEN_VERSION >=6
        std::shared_ptr<netgen::Mesh> mesh_ptr(ngMesh);
        err = netgen::OCCGenerateMesh(occgeom, mesh_ptr, netgen::mparam, startWith, endWith);
#elif NETGEN_VERSION > 4
        err = netgen::OCCGenerateMesh(occgeom, ngMesh, netgen::mparam, startWith, endWith);
#else
        char *optstr = 0;
        err = netgen::OCCGenerateMesh(occgeom, ngMesh, startWith, endWith, optstr);
#endif

My question is: mesh_ptr is used only to satisfy the function attributes. After this function call the mesh_ptr isn't used any more. So it is deleted after the function call? And then the ngMesh is also deleted? Could this be the reason why no mesh is shown?
Is there a way to delete the shared_ptr without deleting the *pointer ?

[ickby]

You don't delete a shared ptr, it gets deleted automatically when it goes out of scope (when you leave your function). The purpose of this shared ptr is Reference counting: when the Last one gets out of scope it deletes the internal Pointer.
This means the Mesh stays valid as long as netgen internally holds one of those shared ptr s. It don't tjink it does from your Small Code slipped. Hence you need to Store the shared ptr somewhere to ensure that at least one of those survives the whole livetime it is needed.