freecad: update to 1.1.1.

[al20ov]

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, x86_64-glibc

New ondsel version, and pycxx is now included in the freecad tarball so there's no need to fetch it separately. But AddonManager is now a submodule so I added that.

[kaistian]

Would it not be better to use https://github.com/FreeCAD/FreeCAD/releases/download/1.1.0/freecad_source_1.1.0.tar.gz that already contain OndselSolver and the AddOnManager?

[al20ov]

Not sure, the last couple people who updated the template decided to stick with the regular archive instead of the one with submodules (which was also available in 1.0.2, 1.0.1, 1.0.0).

[muezabdalla]

now version 1.1.1 has been released
@al20ov if you know who is responsible for merging this kind of PR you can try to mentions him. probably he did not see this PR because it is now not even in the first page

[al20ov]

@muezabdalla I just updated the template to 1.1.1, not much has changed since 1.1.0 and it looks like everything works (that I personally use). CAM works great, I was able to create a toolpath and ran it on my CNC successfully.
It'd be great if you could build this PR and try it out too. It takes a bit of time to build though, I didn't time it but it took 20-30 minutes on an i7 12700H.

[muezabdalla]

@al20ov I test it on mys x86_64 machine and it is working fine.
and because no one merged this yet now there is another PR for the same thing:#59945

[Kruayd]

@al20ov I've tried to compile freecad 1.1.1 independently, then I discovered your pull request. The minimal set of compile time dependencies that I found is the following:

hostmakedepends="doxygen graphviz swig python3-pivy pkg-config"
makedepends="qt6-base-devel qt6-svg-devel qt6-tools-devel vtk-devel
 yaml-cpp-devel python3-pybind11 python3-matplotlib libxerces-c-devel occt-devel
 libmed-devel coin3-devel libspnav-devel libgomp-devel libshiboken6-devel
 libpyside6-devel"

I don't know actually why, but boost is correctly detected at compile time even if there is no boost-devel-minimal in makedepends. Additionally, when xbps-src is building up the run time dependencies list, it correctly sets just libboost_program_options and libboost_thread. Is the boost-1.89.patch still needed?

Regarding shiboken6 and pyside6, i noticed that cmake complains less if it is provided with the development packages instead of just the python3 modules

The set of run time dependencies that I've identified is:

makedepends="qt6-base-devel qt6-svg-devel qt6-tools-devel vtk-devel
 yaml-cpp-devel python3-pybind11 python3-matplotlib libxerces-c-devel occt-devel
 libmed-devel coin3-devel libspnav-devel libgomp-devel libshiboken6-devel
 libpyside6-devel"

python3-vtk is correctly set automatically by xbps-src, while the other missing python3 modules haven't caused any problem yet (but I'm not yet 100% sure that they won't cause any in the future)

Full template:

# Template file for 'freecad'
pkgname=freecad
version=1.1.1
revision=1
build_style=cmake
pycompile_dirs="usr/lib/${pkgname}/Mod"
_inst_prefix=/usr/lib/${pkgname}
configure_args="-DCMAKE_BUILD_TYPE=Release
 -DCMAKE_INSTALL_PREFIX=${_inst_prefix} -DCMAKE_INSTALL_DATAROOTDIR=/usr/share
 -DCMAKE_INSTALL_DATADIR=/usr/share/${pkgname} -DPYTHON_EXECUTABLE=/usr/bin/python3
 -DBUILD_TEST=OFF -DENABLE_DEVELOPER_TESTS=OFF"
hostmakedepends="doxygen graphviz swig python3-pivy pkg-config"
makedepends="qt6-base-devel qt6-svg-devel qt6-tools-devel vtk-devel
 yaml-cpp-devel python3-pybind11 python3-matplotlib libxerces-c-devel occt-devel
 libmed-devel coin3-devel libspnav-devel libgomp-devel libshiboken6-devel
 libpyside6-devel"
depends="python3-pivy python3-pyside6 python3-pyside6-gui
 python3-pyside6-network python3-pyside6-widgets python3-pyside6-svg
 python3-matplotlib python3-ply python3-yaml python3-typing_extensions"
short_desc="General purpose 3D CAD modeler"
maintainer="Orphaned <orphan@voidlinux.org>"
license="LGPL-2.0-or-later"
homepage="https://freecadweb.org/"
distfiles="https://github.com/FreeCAD/FreeCAD/releases/download/${version}/freecad_source_${version}.tar.gz"
checksum=c0e95d41415f1e73bfe2e0a0a28210f649b01ef531bbfed1ed15863950dc5381

post_patch() {
	# Report exact minor version
	# Freecad has a record of shipping mismatching version info
	vminor=${version#*.}
	vminor=${vminor%%.*}
	sed -i -e "s,^\(set(PACKAGE_VERSION_MINOR\) .*,\1 \"${vminor}\")," CMakeLists.txt
}

post_install() {
	# AppHomePath is computed with binary's realpath:
	# do not move binaries but symlink them instead.
	vmkdir usr/bin
	for f in FreeCAD FreeCADCmd; do
		ln -s ${_inst_prefix}/bin/${f} ${DESTDIR}/usr/bin/${f}
	done
}

[zlice]

havent used too much since 1.0.2, but unfortunately they added a 'feature' and do not plan on making an option to change it. every deletion of groups or boolean'ed objects ask "Do you want to delete them as well?" for children.

makes freecad completely unusable for me. not sure what yall wana do but from a quick test this patch fixes it for me. here it is for anyone who comes across this. there's no alternatives as almost everything is subscription and online saves, so i guess i have to rebuild freecad every update.

always-ask-delete-REVERSE.patch

[al20ov]

@zlice I'm not sure void would be thrilled to ship freecad with a patch removing a feature.. I haven't run into this issue myself as I only use freecad for the CAM workbench but it's a shame there's no option to disable it I agree

[sww1235]

@Kruayd or @al20ov did either of you run into issues with errors during do_configure()?

I am getting the following error when attempting to build this patch on top of the current master tip.

=> ERROR: freecad-1.1.1_1: do_configure: 'CFLAGS="-DNDEBUG ${CFLAGS/ -pipe / }" CXXFLAGS="-DNDEBUG ${CXXFLAGS/ -pipe / }" cmake ${XBPS_VERBOSE--Wno-dev} ${cmake_args} ${configure_args} -DCMAKE_POLICY_VERSION_MINIMUM=3.5 ${LIBS:+-DCMAKE_C_STANDARD_LIBRARIES="$LIBS"} ${LIBS:+-DCMAKE_CXX_STANDARD_LIBRARIES="$LIBS"} ${wrksrc}/${build_wrksrc}' exited with 1
=> ERROR:   in do_configure() at common/build-style/cmake.sh:78

Any suggestions?

Trying to get 1.1.1 working, as 1.0.2 has serious bugs with the Assembly work bench.

[sww1235]

Did some further debugging, and found that I had to add guidelines-support-library to my hostmakedepends in order for the do_configure() step to actually run.

@Kruayd

Once it finishes building, I will post my complete template file as an edit to this post.

[kaistian]

It compiles without issue for me without guidelines-support-library because the build system auto detect the dependency and add it automatically.

[sww1235]

It compiles without issue for me without guidelines-support-library because the build system auto detect the dependency and add it automatically.

That's odd, not sure why it wasn't detecting it for me. I am running ./xbps-src pkg freecad inside of the void-packages repo, on a new branch that is rebased on master, with this pull request applied on top.

[sww1235]

Did some further debugging, and found that I had to add guidelines-support-library to my hostmakedepends in order for the do_configure() step to actually run.

@Kruayd

Once it finishes building, I will post my complete template file as an edit to this post.

Got past this issue, but am now having problems with 04-generate-runtime-deps pre-pkg hook not finding libboost_program_options.so.1.90.0 and libboost_thread.so.1.90.0

I have tried with and without boost-devel in my makedepends.

Trying to see if this is defined somewhere on the FreCAD side, or the void-packages side.

[kaistian]

You have some problems with your build environment.
It doesn't seam updated to the latest since latest version of boost is 1.91, and you are trying to use 1.90.

[sww1235]

You have some problems with your build environment. It doesn't seam updated to the latest since latest version of boost is 1.91, and you are trying to use 1.90.

Agreed. Not sure exactly what though.

I wasn't specifically specifying 1.90 boost version though.

Both my system and my copy of void packages are up to date, I blew away my binary-bootstrap and redownloaded. No idea what else I can do at this point.

[kaistian]

You have some problems with your build environment. It doesn't seam updated to the latest since latest version of boost is 1.91, and you are trying to use 1.90.

Agreed. Not sure exactly what though.

I wasn't specifically specifying 1.90 boost version though.

Both my system and my copy of void packages are up to date, I blew away my binary-bootstrap and redownloaded. No idea what else I can do at this point.

Are you sure the branch you are applying this PR is up to date?
Because if you pull this PR and use it directly it will as of writing be 1782 commits behind and boost was updated to 1.91 after this PR was last update.

I just made a branch that is updated that you can use, the only difference this PR is that I removed the boost patch since it's not needed anymore.
https://github.com/kaistian/void-packages/tree/freecad

[al20ov]

@kaistian Can you think of any edits to make before I rebase on top of master? If there's too many things to change I can close this PR and hand it over to you.

EDIT: sorry I misread your message. So no more boost-1.89 patch and it should be good?

[kaistian]

Yes, the boost is fixed i FreeCAD FreeCAD/FreeCAD#24098

[sww1235]

@kaistian Can you think of any edits to make before I rebase on top of master? If there's too many things to change I can close this PR and hand it over to you.

EDIT: sorry I misread your message. So no more boost-1.89 patch and it should be good?

After redownloading this PR and applying on top of master, I was successfully able to compile freecad 1.1.1.

Thanks for taking the time to submit this pull request.

[lemmi]

Looks to me that the bundled source archive has been a regular part for a while. It cleans up the template quite a bit. Might be worth to switch over?
Can you comment on why the qemu build helper was added?

[al20ov]

Sorry the qemu build_helper was left over from before I tried the lrelease cross-build patch so it's not needed anymore. But let me try to see what I can do with the bundled source.

[al20ov]

Okay switching out the archive for the bundled one does clean up the template quite a bit, I was able to build it but it crashes at runtime when I open the CAM workbench. I don't believe it's related to the template at all but rather a fix that was backported into CPython 3.14.6 (python/cpython#149646). Not entirely sure though...

And then the i686 build failure is related to #60319. Do I work around it just for i686?

[lemmi]

Can you push the template? I'm waiting for 1.1 especially for the CAM updates. So maybe I can spot something.

[lemmi]

Something is broken.

1. If I do my usual git merge-pr, I get tons of patch errors
2. checking out your branch also seems to confuse things, but it builds, but I get

   SONAME: libvtkWrappingPythonCore3.14-9.5.so.1 <-> UNKNOWN PKG PLEASE FIX!
   SONAME: libvtksys-9.5.so.1 <-> vtk>=9.5.0_1
   SONAME: libxerces-c-3.2.so <-> libxerces-c>=3.2.0_1
   SONAME: libyaml-cpp.so.0.8 <-> yaml-cpp>=0.8.0_1
   SONAME: libz.so.1 <-> zlib>=1.2.3_1
=> ERROR: freecad-1.1.1_1: cannot guess required shlibs, aborting!

Is this branch properly rebased on master?

[al20ov]

My bad, I forgot to add common/shlibs

[lemmi]

1. you should probably rebase the branch, seems to be 2 weeks ago the last time that happened
2. the CAM crash goes away when preloading libexpat LD_PRELOAD=/usr/lib/libexpat.so.1 /usr/bin/FreeCAD which lead me to rebuild python3 locally, which also seems to fix it.

so:

1. xrevbump "rebuild for expat" srcpkgs/python3/template
2. then you rebase and bring things in order
3. then we'll see

[al20ov]

Revbumping python3, adding my FreeCAD changes, then rebuilding everything, then reinstalling the local, rebuilt copy of python3 and then FreeCAD did not fix the CAM workbench crash for me unfortunately... However, LD_PRELOAD=/usr/lib/libexpat.so.1 FreeCAD does.

Also for the rebase, this branch is confusingly named freecad-1.1.0 instead of freecad-1.1.1 because that's what I opened the PR for originally but I noticed I also had a branch named freecad-1.1.1 on my fork which is 2 weeks old, are you sure you weren't accidentally using that one? I just deleted it to prevent any mistakes for myself.

[JkktBkkt]

i686 build of freecad succeeds after this is applied (and vtk is rebuilt)
vtk.patch

However, if I understand that line properly, changing it would be necessary in order to build vtk cross to another architecture and have it picked up by packages dependent on it. It might make sense to remove the conditional altogether and apply the same mangling on all architectures?

[al20ov]

It might make sense to remove the conditional altogether and apply the same mangling on all architectures?

That's what I was thinking too so I asked about it but I still don't understand the reason for the conditional: #60888

I take it that you tried it on x86_64 too? Did you run into the same segfault I did when entering the CAM workbench?

[JkktBkkt]

reason for the conditional

Looked at it a bit more, and noticed that vtk for aarch64-musl (checked as example because armv6l* / armv7l* failed) built fine and got picked up by freecad, and the path in the /usr/aarch64-linux-musl/usr/lib/cmake/vtk-9.5/VTKPython-targets-none.cmake is mangled correctly.

Since this needs to be ran only in native builds, perhaps this would be the better approach?
vtk-take2.patch
This should eventually let it build on aarch64 native too.

tried it on x86_64 too?

not yet, no

[JkktBkkt]

Re: crash when entering CAM workbench

I do not get one, but I have also built everything from source. That included switching jxrlib to a fork and unbundling things from freeimage, otherwise I got build failures in them (and couldn't build occt)

On a different note, similar to previous previous situation, when building HDF5, VTK and freecad, aarch64 native builds succeed (can't really test is CLI-only)

In order to let aarch64 users build only freecad native, changes are necessary to HDF5 (I had that working for a test but it required 100k+ lines diffs from HDF5's master at the time, which I decided against opening a PR for): building freecad native gets to salomesmesh and then fails to find HDF5 in cross-built VTK, and then trying to build VTK leads to it not finding cross-built HDF5, but this is a known issue.

Using both HDF5 and VTK native built on aarch64 and building freecad works.