Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Dr-Terrible opened this issue Nov 26, 2020 · 5 comments · May be fixed by #297
Open

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

Dr-Terrible opened this issue Nov 26, 2020 · 5 comments · May be fixed by #297
Assignees

Comments

@Dr-Terrible
Copy link

Dr-Terrible commented Nov 26, 2020

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
Copy link
Owner

waebbl commented Nov 26, 2020

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
Copy link
Author

Dr-Terrible commented Nov 26, 2020

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
Copy link
Owner

waebbl commented Nov 27, 2020

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
Copy link
Author

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
Copy link
Owner

waebbl commented Jan 28, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants