Tested locally that build succeeds with all other components being
header-only or unused by now.
`regex` is only needed for Boost <1.76, see
https://www.boost.org/releases/1.76.0/
CGAL never runs `find_package` for `Boost`, `GMP` or `MPFR` during its configuration and never hardcodes their paths to the generated configs. So providing them have no effect. It's also can be confirmed by `build-deps.cmd` on Windows running all this time without the most of these args. Though it was settings `BOOST_ROOT` but it had no effect too.
Probably it's some kind of artifact from CGAL past when it's used to be non-header-only library.
`BOOST_VERSION_UNDERSCORE` unused since 2e35b07
`OCE_LOCATION` is dead since it was introduced 72d8b5377 (and was a dead variable in build-all.sh too)
`curl`, `wget` - replaced with `urlretrieve back in 51cf52c38
Moved `BOOST_LOCATION` next to its `build_dependency`, so it will have a harder time getting lost.
Example error coming from Linux build (`build_rocky` is bringing ISU dev libs transitively through pango/cairo):
```
./BonsaiViewer: error while loading shared libraries: libicudata.so.67: cannot open shared object file: No such file or directory
```
As it installs everything to `lib`, making it hard to filter things that are needed just for Python wrapper (e.g. skipping qt libs). Anyway we deploy everything ourselves manually in `package-zip-archives`.
Led to error during OpenCOLLADA build:
```
2026-08-28 13:33:34,391 make[2]: *** No rule to make target `/Users/runner/work/IfcOpenShell/IfcOpenShell/build/Darwin/arm64/10.15/install/pcre-shared-8.41/lib/libpcre.so', needed by `lib/libOpenCOLLADABaseUtils.dylib'. Stop.
2026-08-28 13:33:34,391 make[2]: *** Waiting for unfinished jobs....
```
Just to use consistent patches between the builds. It was previously guarded by `WASM`, but it was a dead code - `OpenCOLLADA` is skipped on wasm, so it was never exercised.
Regarding the "specializing std::hash outside of the std:: namespace" issue on gcc - it was caused by patch missing fixes for `COLLADABU_HASH_NAMESPACE_OPEN` and `COLLADABU_HASH_NAMESPACE_CLOSE`. So in theory it should have also result in an error in clang or in an invalid code/ub. Either way, now it's fixed.
Andrej730