Created attachment 229600 [details] Configure Fails.log if you have math/qhull installed CMake detects it during configure but cannot use complaining about this for various missing components. see attached log CMake Error in src/qhull/CMakeLists.txt: IMPORTED_LOCATION not set for imported target "Qhull::qhullcpp" configuration "Release". if one patches src/qhull/CMakeLists.txt by disabling check for system qhull it will just use the bundled package. see subsequent configure logs individual patch for files/ and the git diff if that is easier.
Created attachment 229601 [details] Configure after patch applied.log after patching src/qhull/CMakeLists.txt by new files/patch-src_qhull_CMakeLists.txt
Created attachment 229602 [details] git_diff_patch_src_qhull_CMakeLists.txt.diff git diff to add the file
Created attachment 229603 [details] patch-src_qhull_CMakeLists.txt or if you prefer copy this to files/ for conveniences sake
If you upgrade Qhull to 2020.2, i.e. 8.0.2, dated 2020/08/31, does it fix the build for PrusaSlicer? Just asking, because the recent release of SageMath requires 8.0.2.
(In reply to Thierry Thomas from comment #4) I mean: math/qhull8 is in the tree.
I'll take it.
(In reply to Thierry Thomas from comment #5) I think this port has its own qhull built in. So the idea of the patch is to stop it from using the qhull that already exists.
(In reply to Thierry Thomas from comment #5) sure if you don't mind breaking FreeCAD (more), gdal, and 90% of the engineering applications I use to use the conflicting version of qhull they don't use. What is the point of slicing STLs if the major way of drawing them is unable to use the qhull version the slicer uses??? Technically after wasting much time enlarging my test 12.2 bhyve to build the laundry list of depends, it does seem to allow building using qhull8, but it is at a totally unacceptable cost, I'd rather run a custom ports tree to hack it out anyway, as thats the only way to get equivalent functionality of people using packages. Why is there a push to not allow repeatable builds between package building and the HandBook Specified way of using Live System Building with Ports??? In typical Cmake fashion it makes no check if the found versions are correct, it has no options to disable using the junk cmake finds, so its checks should be disabled until Upstream adds perhaps some simple Cmake variables/options to allow more proper switching of options for the project. Perhaps I'll reach out to Josef, but I just want to use my printer, and theoretically draw things once the OpenCascade issues are fixed with FreeCAD.The CMake issues place us at the mercy of upstream, but that doesn't mean they shouldn't be mitigated against. Or am I being unreasonable?
(In reply to Stephen Montgomery-Smith from comment #7) exactly, if a port doesn't list a dependency, it should not be using external dependencies. I understand, especially with CMake, that this is not always possible, but basic repeatability between Packaging building and Live System building should be something we strive for when possible, especially given how many conflicting versions of ports we have in the tree. I don't think its fair to penalize me using live system building for years if not a decade before poudrier even existed, because lazy upstream code assumes if it finds it it uses it without bothering to check if the version is even compatible. If poudrier expects to use the bundled version, so should ports.I wish it could be more elegant, but the build scripts of the port itself are themselves flawed.
(In reply to alt2600 from comment #8) It does seem to be the case that the ports process breaks down when dependent ports update their versions with incompatible API. This is why I introduced a new port called qhull8, because I saw that converting qhull to 8.0.2 would break a lot of things. So in effect, I punted on the issue of what to do if one wants to install several different ports, some of which depend upon qhull, and some of which depend upon qhull8. What I could do is to redo qhull8 so that all the files installed call it qhull8 (effectively s/qhull/qhull8/ on pkg-plist). Then both ports can be installed without conflicts, and those who want to use the new qhull can do so by editing the library and include names.
(In reply to alt2600 from comment #9) Right. Your bug fix is a band aid solution to the problem. But until something better comes along, I think it is totally reasonable. I will wait another day for portmgr@ to reply to my request to commit this PR (seeing as the maintainer seems to be not replying), and then commit it.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=59fb9b948f46dc099ce54d623b69c809f0a75b98 commit 59fb9b948f46dc099ce54d623b69c809f0a75b98 Author: Stephen Montgomery-Smith <stephen@FreeBSD.org> AuthorDate: 2022-01-15 17:47:08 +0000 Commit: Stephen Montgomery-Smith <stephen@FreeBSD.org> CommitDate: 2022-01-15 17:47:08 +0000 cad/PrusaSlicer: Fix build when math/qhull is present. Maintainer timeout. PR: 259941 Reported by: alt2600@icloud.com .../files/patch-src_qhull_CMakeLists.txt (new) | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+)
Committed.
(In reply to alt2600 from comment #8) Well, I've just submitted several PRs to switch from Qhull 7 to Qhull 8. See PR 261280, PR 261281, PR 261282 and PR 261283. If they get approved by their maintainers, I hope to commit them at the same time.
(In reply to Thierry Thomas from comment #14) again, it shouldn't matter what version of qhull is in tree as long as it works for its dependencies, this port lists no dependency to qhull. People using poudrier shouldn't get working ports that don't use dependencies that get pulled in by sloppy cmake build systems from upstream code that folks following the documentation for Freebsd get broken ports over. The upstream code should not accept finding qhull.h or whatever without even validating its a valid version of the library. Also, in a perfect world, outside of knobs set, people building from ports and poudrier should get the same package. This is an ideal that I think should be striven for, despite it being difficult for many reasons, such as defaults for configures/cmake that enable if found but are not disabled in the port (or not possible through normal means to disable with configure/cmake args), or other obscure interdependence issues surrounding how knobs effect downstream dependencies sometimes (firefox runtime breaks if you have tiledb installed for gdal, or it was broken haven't tried since, breaks sqlite use in firefox it seems instead trying to use tiledb instead based on ldd but as far as I dug before fixing my knobs). If we decide to go to qhull 9 this port shouldn't break, it should use bundled, if we have to revert to qhull 7 this port shouldn't break it should use bundled, if the specific version of qhull 8 goes up minors, this port shouldn't break, it should use bundled, it has no dependency on qhull as ported, or at least it shouldn't based on its makefile or it should be documented as a dependency so it gets tracked as a dependency, and poudrier equally brings it in. All I wanted was for the ports and poudrier to build with the same bundled version of qhull, not that I have to care what random conflicting version of qhull I have in the system so I can make sure an undocumented/untracked dependency is satisfied, ain't no one have time for that. But most importantly, this port should use bundled because that is what our package building system does, and there is no knob to change that function, unexpectedly using system qhull is a configure/build bug. The fact qhull8 works now doesn't mean it will work tomorrow for this port. Users of ports shouldn't be second class citizens to users of poudrier/pkgs. Not if we want more people using freebsd who already complain the installer is hard to use. Lets shove them into the world of untracked dependencies, when they might not even know what make is yet in the first place, that will surely add to the user base. So I hope the major update goes well for you, and the fallout is minimal.