Packaging solution: (ana)conda

[looo]

I added gmsh to the freecad channel. It was easy to build on linux, but no chance on windows. (missing libraries gdb, slapc, petsc...)

[sgrogan]

but no chance on windows. (missing libraries gdb, slapc, petsc...)

I think this is not a big deal. FreeCAD (FEM) only calls the gmesh executable in a sub-process. The gmsh.exe is readily available and the user only needs to install it and set the path in fem > preferences. It looks like gmsh.exe is statically linked because only the .exe has to be added to bin (no dll's) of the portable builds.
In the future maybe addons-manager can handle this? It's included in the Win-bundle only as a user convenience. On Linux (PPA) the user must use their package manager to install gmsh and then set the path in FreeCAD.

[looo]

yes, it's not a problem for freecad, but it shows that msys is still the prefered way to get opensource work on windows...
If you think about it, compiling a os project with a closed source compiler is not the best idea...

[kkremitzki]

yes, it's not a problem for freecad, but it shows that msys is still the prefered way to get opensource work on windows...
If you think about it, compiling a os project with a closed source compiler is not the best idea...

+1 to this. When I wanted to set up a Windows dev VM and had to try to use Microsoft websites to get software it felt like I was back in the stone ages... I'm sure their marketing/sales department has overruled software engineering concerns to make it difficult to find old stuff, if not remove them altogether.

[easyw-fc]

yes, it's not a problem for freecad, but it shows that msys is still the prefered way to get opensource work on windows...
If you think about it, compiling a os project with a closed source compiler is not the best idea...

+1 to this. When I wanted to set up a Windows dev VM and had to try to use Microsoft websites to get software it felt like I was back in the stone ages... I'm sure their marketing/sales department has overruled software engineering concerns to make it difficult to find old stuff, if not remove them altogether.

+1 ... kicad also deploys Msys2 builds for windows

[saso]

http://blog.llvm.org/2018/03/clang-is-n ... e-for.html

Edit: How does debugging or similar compare to the msvc builds?

[looo]

yes clang is also an option. So this means we could slowly move dependencies towards clang. I guess this is the easier option. But who knows what strategy will be choosen for conda-package. Clang seems really the most promising. As far as I know openblas [1] is build this way for windows. And scipy [2] seems to be the next library which tries to use clang/flang toolchain.
But the problem with clang/flang is that is not well tested.

Some experiments with mingw/msys showed me that it is also not that good supported for conda. At least I wasn't able to build openmpi this way. And there are many libraries which use mpi...

So no idea which way to support. If there is mpi for the mingw-toolchain, I guess this would also open some doors.

[1] https://github.com/conda-forge/openblas ... a.yaml#L35
[2] https://github.com/conda-forge/scipy-feedstock/pull/78

[looo]

libmed was accepted: https://github.com/conda-forge/libmed-feedstock

So once the builds are uploaded, nothing should prevent from building freecad with osx and conda-dependencies.

[Jee-Bee]

libmed was accepted: https://github.com/conda-forge/libmed-feedstock

So once the builds are uploaded, nothing should prevent from building freecad with osx and conda-dependencies.

Congrats i would say py3

[easyw-fc]

Hi @loo
I'm testing the conda builds here
https://github.com/sgrogan/FreeCAD/rele ... it_package
and here
https://github.com/FreeCAD/FreeCAD/rele ... g/0.18_pre (FreeCAD-0.18-dev_PY3_QT5-x64_dev_win.7z)
What I've noticed is that the View get updated lately in Conda version, compared to the same release on standard old mode build
(FreeCAD_0.18.13554_x64_dev_win.7z)

Here a small screencast:

py3-qt5-update-view.gif (646.65 KiB) Viewed 1302 times

In the first part of the screencast (FC std build) the loading is progressive and objects are loaded and updated as they get imported,
in the second part of the screencast (FC conba build), the loading is locked until all objects are imported and only at the end they get updated.

This may become an issue for my WB when the board have hundreds of sub-parts because the interface just freezes until the end of the loading process.

To test it locally you only need to install kicad StepUp WB through the Addon installer...

Thx for having a look at