https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223678
--- Comment #12 from Christian Pfeiffer <cpfeif...@live.de> --- @adriaan I had a look through the cmake ports description and noticed you generally replace `/usr/local` with $LOCALBASE using sed and applied some patches. >From what I explained above, it's in both CMake's and FreeBSD's best interest to keep the number of patches and adaptions needed as small as somehow possible. For one, upstream does nightly testing with *unpatched* CMake trunks, and that includes FreeBSD test machines. Secondly, some packages require FreeBSD specific adaptations going beyond just replacing `/usr/local` with $LOCALBASE, e.g. FindMPI needs to consider all subdirectories for `/usr/local/mpi` and that's something just introduced with 3.10 now. I think the `/usr/local` hard coding is an issue that needs addressing in CMake itself instead of patching it downstream. One of the reasons is that by simply replacing `/usr/local` using sed, you'll get strange results for cross-compilation builds using a `CMAKE_SYSROOT` where it should be `/usr/local`. For OpenBSD this issue is as a matter of fact addressed upstream, see here: https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/OpenBSD.cmake#L28-37 The exact same approach could be used for FreeBSD. Given the other path replacements, I think the approach used in the OpenBSD platform file would address all of these, but it needs a bit of testing. I can cook up a patch upstream and we can see if that already works out? Regarding the patches: The wxWidgets, wxWindows and ImageMagick ones could be merged upstream as is. The FindSDL one should be done with care, if you install SDL manually in an isolated prefix environment, system CMake would then always include the system path - this breaks cross compilation environments for instance. The superior choice would be to use `find_path` to determine the header path in order to not break I'm not quite certain what the FindQt4 one is trying to achieve, but it will overwrite user-set variables and also break cross compilation scenarios due to `CMAKE_SYSROOT` not being searched anymore. If there's a scenario where this is needed, that sounds like a bug in the module. In general, given CMake's set goals, you should consider any downstream bug for CMake an upstream bug as well. FreeBSD is a platform that CMake strives to support fully and needed downstream adjustments are therefore a bug. -- You are receiving this mail because: You are the assignee for the bug.