ana(conda) windows packaging
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: ana(conda) windows packaging
Maybe we should try to write a test for the xerces-c and zlib feedstocks.
Re: ana(conda) windows packaging
* libMed is now using the conda-forge hdf5. :issue solution
The libmed package had similar issues like we currently see with FreeCAD. This was solved by adding a library which the hedf5 library depends on. So maybe we have to something similar with freecad.
* added vc 14 as dependency for netgen, libmed, pivy and coin3d
* I had a look into the occt feedstock. There we are using tk8.5. Regarding this issue we should have taken 8.6 which is shipped with the python interpreter... But there are no headers available, so it's not possible to update the feedstock to tk8.6.
Maybe we can try to build occt without tk.
The libmed package had similar issues like we currently see with FreeCAD. This was solved by adding a library which the hedf5 library depends on. So maybe we have to something similar with freecad.
* added vc 14 as dependency for netgen, libmed, pivy and coin3d
* I had a look into the occt feedstock. There we are using tk8.5. Regarding this issue we should have taken 8.6 which is shipped with the python interpreter... But there are no headers available, so it's not possible to update the feedstock to tk8.6.
Maybe we can try to build occt without tk.
Re: ana(conda) windows packaging
This basically means disabling the DRAW test harness.looo wrote:Maybe we can try to build occt without tk.
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: ana(conda) windows packaging
It was defunct for me anyway (and most likely for everyone else on Windows), so no big loss Or maybe it works in sgrogan's OCC7 libpack, I haven't tried ...NormandC wrote:This basically means disabling the DRAW test harness.looo wrote:Maybe we can try to build occt without tk.
Re: ana(conda) windows packaging
doing this as long as there is no consistency with tk with anaconda.NormandC wrote:This basically means disabling the DRAW test harness.
Re: ana(conda) windows packaging
Just for the record, I was only stating fact, not voicing disapproval.
I have the very limited knowledge of OCCT that being an end user provides me, but it seems to be purely an OCC development tool. Apart from using DRAWEXE for reporting geometry bugs upstream, I can't see its use for FreeCAD.
I have the very limited knowledge of OCCT that being an end user provides me, but it seems to be purely an OCC development tool. Apart from using DRAWEXE for reporting geometry bugs upstream, I can't see its use for FreeCAD.
Re: ana(conda) windows packaging
short question:
could it be that this https://github.com/looooo/FreeCAD/blob/ ... s.txt#L148 overwrites all library-paths and uses paths according to the libpack ???
and also this has potetential to be root of our linking problem:
https://github.com/looooo/FreeCAD/blob/ ... t#L973L999
could it be that this https://github.com/looooo/FreeCAD/blob/ ... s.txt#L148 overwrites all library-paths and uses paths according to the libpack ???
and also this has potetential to be root of our linking problem:
https://github.com/looooo/FreeCAD/blob/ ... t#L973L999
sorry, I periodically loose the orientation in the dependency hell good to have someone who has an overview.NormandC wrote:Just for the record, I was only stating fact, not voicing disapproval.
Re: ana(conda) windows packaging
Yes! After finding that out this morning, I discovered this article that explained why.
Note that this only fixes the CRT linking errors. There are still others.
PR: https://github.com/looooo/FreeCAD_Conda/pull/5If you link with the /nodefaultlib option, you will need to link several extra libraries when you link. For example, whereas you previously might have just linked msvcrt.lib in order to use the CRT DLL, you will now also need to link vcruntime.lib and ucrt.lib.
Note that this only fixes the CRT linking errors. There are still others.
Re: ana(conda) windows packaging
I don't really but I've had my own dependency hell troubles with packaging OCCT 7.1 for the Ubuntu PPA (good thing I got great help too or I would still be stuck). A few months ago an OCCT developers signed in to the forum and posted some short but useful info regarding third-party dependencies in the OCCT Ubuntu packaging topic:looo wrote:good to have someone who has an overview.
https://forum.freecadweb.org/viewtopic. ... 80#p142368
The opencascade.org website also has a set of Overview pages for their modules, here's the one for the DRAW Test Harness:
https://www.opencascade.com/content/draw-test-harness
I don't recall why we need to use tcl/tk 8.5 rather than 8.6 on Debian/Ubuntu.
Re: ana(conda) windows packaging
wow thanks @peterl94 . This is a big step forward.
Next round:
building with everything disabled gives a linking problem with PyCXX:
regarding this https://sourceforge.net/p/cxx/mailman/message/34599093/ something isn't linked correctly with src/CXX/IndirectPythonInterface.hxx .
building with everything enabled, smesh explains about a not possible conversation:
Is there a reason to pass a "handle" by reference? Isn't the handle like a smart-pointer?
seems like a long way to go
Btw: deleted the occt build on the freecad-channel, so it now pulls from conda-forge again. There were some libraries missing with the occt build without tk (TKMeshVS).
Next round:
building with everything disabled gives a linking problem with PyCXX:
Code: Select all
MaterialPyImp.cpp.obj : error LNK2001: Nicht aufgel÷stes externes Symbol ""void __cdecl Py::_XINCREF(struct _object *)"
building with everything enabled, smesh explains about a not possible conversation:
Code: Select all
C:\Users\fc-builder\Miniconda3\conda-bld\freecad_1490502689427\work\src\3rdParty\salomesmesh\src\StdMeshers\StdMeshers_QuadToTriaAdaptor.cpp(767): error C2664: "int StdMeshers_QuadToTriaAdaptor::Preparation(const SMDS_MeshElement *,Handle_TColgp_HArray1OfPnt &,Handle_TColgp_HArray1OfVec &,std::vector<const SMDS_MeshNode *,std::allocator<_Ty>> &,gp_Pnt &,gp_Vec &,const SMDS_MeshElement **)" : Konvertierung von Argument 2 von "opencascade::handle<TColgp_HArray1OfPnt>" in "Handle_TColgp_HArray1OfPnt &" nicht möglich
seems like a long way to go
Btw: deleted the occt build on the freecad-channel, so it now pulls from conda-forge again. There were some libraries missing with the occt build without tk (TKMeshVS).