Closed looooo closed 3 years ago
trelau
commented
4 years ago i've been debating on how to best do this....i'm wondering if it can't be done via some build script that clones the repos and applies patches and builds...so easier to update
for now, when i have time, i've been wanting to get a pyOCCT done for 7.3.0 and then 7.4.0...then seeing if i can't get SMESH 8.3.0 synced to that...then dealing with SMESH update to 9.3.0
looooo
commented
4 years ago Is there no way to apply patches on the salome smesh repo?
trelau
commented
4 years ago well...i think there are some read-only repos mentioned here https://git.salome-platform.org/gitweb/
and i think there some more work to be able to contribute to Salome itself.....maybe not impossible...but might take a while
trelau
commented
4 years ago @looooo fwiw, i updated master 8.3 to OCCT 7.4.0...working towards getting pyOCCT up to OCCT 7.4.0...then will decide how to best handle SMESH 9.3 and beyond
thinking about a repo that just builds SMESH from the Salome sources..but that could get tricky handling the Netgen integration since Salome seems to still be using Netgen 5.X...
also considering making the Python bindings separate from pyOCCT...so something like pySMESH
looooo
commented
4 years ago Smesh is holding freecad back from moving towards occt7.4 and freecad without smesh is a big step in wrong direction as the fem-module heavily depends on smesh and this module is quite popular... So thanks for the information. I hope some people from freecad will join the initiative to join the efforts. I will try to encourage people to support your fork instead of our freecads internal fork. Doing work twice is already frustrating enough, but doing work 3 or 4 times is simple stupid (imo).
Regarding pyocct7.4: great, maybe we manage to setup a conda-forge recipe for pyocct this time. Not sure what prevented us from doing so last time.
trelau
commented
4 years ago @looooo sounds good...i think the main bottleneck on the pyOCCT conda-forge was a limit on build times...lately i've been looking into using Azure Pipelines which seem to offer unlimited build times and parallel builds for public projects..i'm thinking about migrating to that and away from appveyor/travis for all my projects once i stabilize the 7.4.0 pipeline
note: all the work between smesh and pyOCCT for OCCT 7.4.0 has been done on windows..so mac and linux support might have some catching up to do
you might find interest in this thread on the pythonOCC project (which has since updated to OCCT 7.4.0 but for now dropped support for SMESH) https://github.com/tpaviot/pythonocc-core/issues/745#issuecomment-569951252
i'm not sure there is a compelling case for either SWIG or pybind11...i'm using pybind11 as more of a hobby project at this point because i find it interesting...but both seem to get the job done...maybe the freecad community has a preference and/or reasons?
trelau
commented
3 years ago I have a local branch that I haven't pushed yet experimenting with the approach proposed above (just making a repo that downloads the latest Salome sources and builds)
The good:
The maybe not so good?:
@looooo any thoughts on the approach and making this trelau/SMESH repo behave as described above?
edit: i pushed the experimental branch, though the CI workflow isn't updated yet
trelau
commented
3 years ago @wwmayer any thoughts on the above approach and direction for this project?
trelau
commented
3 years ago Addressed in https://github.com/trelau/SMESH/pull/31
Issue description
Occt7.4 is available and it seems like their mesh libraries changed a lot. So this version of smesh doesn't seem to be compatible anymore and we should update to the latest salome smesh.
Reproducible example code
Building with conda: https://github.com/conda-forge/smesh-feedstock/pull/27
I wonder if this can be done in an automated way. This fork seems to be not compatible with upstream anymore but I guess directly building upstream is also no option. So some how the projects need to merge. Is there any good strategy to do so?