Conda(Docker)/AppImage Failure

[looo]

I have vs2017 still installed, so maybe it's easier if I do the testing. But I am not quite sure how to use the dependency-walker.

I should be able to install vs2017 on the weekend. I'd really like to learn how to do this.
Dependency-Walker seems to have died. They don't claim compatibility for Win10, although I haven't tried since I upgraded to Win 10 http://dependencywalker.com/
This may be an alternative https://github.com/lucasg/Dependencies

another idea is to update netgen 6.2.2006 and build it with the latest occt/vtk and use git to pull sources as this will set the version (hopefully) in a correct way. Somehow I think the issue with 6.2.2007 is related to netgen changes. So it would be nice to see what is wrong, but if we manage to get 6.2.2006 to work with smesh there is not much disadvantage.

[sgrogan]

another idea is to update netgen 6.2.2006 and build it with the latest occt/vtk and use git to pull sources as this will set the version (hopefully) in a correct way. Somehow I think the issue with 6.2.2007 is related to netgen changes. So it would be nice to see what is wrong, but if we manage to get 6.2.2006 to work with smesh there is not much disadvantage.

I did notice when running conda debug that it used vtk9, before I realized I needed VS2017. Maybe netgen 6.2.2006 uses vtk 8.x?
I'm reading this https://docs.conda.io/projects/conda-bu ... index.html
Is there a quick start?
I've got a lot to learn to understand how this works

[looo]

I did notice when running conda debug that it used vtk9, before I realized I needed VS2017. Maybe netgen 6.2.2006 uses vtk 8.x?

I didn't manage to get vtk9 pulled without explicite pinning vtk in the meta.yaml. see also this pr. Linux and osx are now pulling vtk9. This is actually not very important for netgen (as netgen does not need vtk at all...)

Anyway v6.2.2006 has incorrect version config and therefore leads to the smesh configuration issues...
So the easiest way (in my mind) is using v6.2.2006 + pulling sources with git. Anyway it would be nice to know what the netgen 6.2.2007.

The principles of conda-build are not that difficult. It simple combines pulling deps & sources + compilation + creating the package from the diff in the host-env. The host and build-env is necessary to avoid compiler-stuff being installed into packages.

[looo]

After seeing that vtk9 support needs more work [1] I tried to fix the linux issue in another way. The difference between my local build and the ci-build was the channel-priority. Locally I used "flexible" and the ci used "strict". Strict means that packages of higher priority channels (freecad-channel) are selected. So I guess a package on the freecad-channel was selected (maybe a newer netgen) which leads to conflict with conda-forge packages (as there might be no compatible smesh).
So for now I simply disabled the freecad-channel and use conda-forge + defaults only.

So I guess we will continue building against vtk8.2 and wait until someone comes up with a solution for smesh + vtk9. Maybe we should ask if vtk-developers can give some hints about the vtk9 support.

[1] https://forum.freecadweb.org/viewtopic. ... 20#p408190

[sgrogan]

So for now I simply disabled the freecad-channel and use conda-forge + defaults only.

Ahh, I see. Still don't know which package
I don't know how you found the Win build failure? A missing EOF/CR? Where did that come from?
https://github.com/looooo/freecad-feeds ... 46a0e1e5a2

[looo]

So for now I simply disabled the freecad-channel and use conda-forge + defaults only.

Ahh, I see. Still don't know which package
I don't know how you found the Win build failure? A missing EOF/CR? Where did that come from?
https://github.com/looooo/freecad-feeds ... 46a0e1e5a2

this came up after rerendering. we had this issue already some time ago.