search

waebbl / waebbl-gentoo

Personal overlay of gentoo ebuilds, loosely focused on the 3D domain.
17 stars 17 forks source link

[media-gfx/freecad] Make the Web Workbench optional #264

Open Dr-Terrible opened 3 years ago

Dr-Terrible commented 3 years ago

media-gfx/freecad-0.18.4-r1::waebbl unconditionally enables the Web Workbench module. This module (as stated in the official Wiki) is not a modelling workbench but merely provides a convenient web browser window within the app itself; it doesn't enhance FreeCAD with extra 2D/3D features.

The module uses dev-qt/qtwebkit:5, which soon is going to be retired from portage. QtWebKit is deprecated in favour of QtWebEngine, which means upstream is going to switch to QtWebEngine for their Web Workbench. Both QtWebKit and QtWebEngine impose a heavy burden on specific archs (ex.: dual-core x86, or 64-bit ARM with limited amount of RAM such as Raspberry Pi or similar hardware) causing compilations that can last for more than 24-48 hours. Cross-compilation is not an option either, because VTK, QtWebKit, QtWebEngine, nor several other FreeCAD's dependencies are designed to properly support it.

It would be nice to hide the Web Workbench behind a web USE flag, so people with constrained resources can skip the dependency on dev-qt/qtweb*. It's a trivial modification to the ebuild, and I can provide a pull request if this feature request is accepted.

waebbl commented 3 years ago

Hi @Dr-Terrible, thanks for the request. AFAIK the web workbench is a prerequisite for the start workbench which is loaded upon startup for FreeCAD, so I doubt whether it's possible to make this workbench truly optional, see REQUIRES_MODS lines in the CMakeList.txt file.

Feel free to experiment with it and give it a try. If you come up with a useable solution, I'm gonna accept it.

Dr-Terrible commented 3 years ago

AFAIK the web workbench is a prerequisite for the start workbench which is loaded upon startup for FreeCAD, so I doubt whether it's possible to make this workbench truly optional, see REQUIRES_MODS lines in the CMakeList.txt file.

True, but the most recent version of the REQUIRES_MODS macro disables the parent scope in case the dependency is explicitly disabled by the user; which means that disabling BUILD_WEB also disables BUILD_START.

Backporting the new macro from the v0.19 branch to the v0.18.4 and v0.18.5 branch is literally a single line patch. It's doable.

Feel free to experiment with it and give it a try. If you come up with a useable solution, I'm gonna accept it.

I'm testing right now, I'll report as soon as I finish some checks.

In the worst case scenario, I'll force CMake to only accept dev-qt/qtwebengine:5 instead of dev-qt/qtwebkit:5; at least the ebuild would be ready when qtwebkit is removed from portage. At the moment qtwebkit is pulled-in by both media-gfx/freecad::waebbl and sci-libs/vtk-0.8.2-r2::waebbl. sci-libs/vtk-0.8.2::gentoo has already been fixed; I can easily backport that fix too, but I'm not sure if in the future you want to keep a separate ebuild from the one in portage.

waebbl commented 3 years ago

True, but the most recent version of the REQUIRES_MODS macro disables the parent scope in case the dependency is explicitly disabled by the user; which means that disabling BUILD_WEB also disables BUILD_START.

Backporting the new macro from the v0.19 branch to the v0.18.4 and v0.18.5 branch is literally a single line patch. It's doable.

Great! Currently I'm not following the upstream work closely, because I'm quite busy with real live work. If there are no runtime issues and FreeCAD can safely be used without the start workbench, this is a good move.

In the worst case scenario, I'll force CMake to only accept dev-qt/qtwebengine:5 instead of dev-qt/qtwebkit:5; at least the ebuild would be ready when qtwebkit is removed from portage. At the moment qtwebkit is pulled-in by both media-gfx/freecad::waebbl and sci-libs/vtk-0.8.2-r2::waebbl. sci-libs/vtk-0.8.2::gentoo has already been fixed; I can easily backport that fix too, but I'm not sure if in the future you want to keep a separate ebuild from the one in portage.

I don't necessarily want to keep a separate vtk ebuild in my overlay. The ebuild started when ::gentoo was behind with the vtk versions and I later kept it, when I encountered some issues with the official ebuild. I have to check some details on the ::gentoo ebuild before I gonna decide whether to remove the ebuild from my overlay. IIRC tk was no longer supported with 8.2.0, but the ebuild still has the USE flag.

Dr-Terrible commented 3 years ago

Thank you for the updated ebuilds for v0.18.5 and v0.19; I re-based my PR on top of them.

In my pursuit for testing FreeCAD's features with the Start/Web Workbench disabled, I also discovered that the FEM Module was missing a dependency on the Material Module; I fixed that too in the PR.

So far, I have used both FreeCAD v0.18.5 and v0.19 for the past month without issues, everything seems to work as expected.

waebbl commented 3 years ago

Thank you for your effort. I'm gonna review the PR tomorrow.