6dbc4e28d raised the minimum CGAL to 5.4. The Windows dependency cache in
build-outputs is keyed on the install directory name and only ever adds to
it, so the unversioned `cgal` directory kept serving CGAL 5.2.3 and the
Windows build has failed at configure since:
Could not find a configuration file for package "CGAL" that is compatible
... cgal/lib/cmake/CGAL/CGALConfig.cmake, version: 5.2.3
Name the directory `cgal-5.5.5`, as the TODO already suggested, and record
it in the deps cache like the other installers do.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Also drop-in replacement mostly, except extra cmake args need to be provided now after `--` - `python run-cmake.py vs2022-x64 -- -DGLTF_SUPPORT=ON`.
Internally, script relies on env variables much much less.
Mainly drop-in replacement for `build-ifcopenshell.bat` with `--help`, kw args and args validation, but there's a small caveat.
Previously it was possible to pass args to the underlying build tool as simple positionals - e.g. `build-ifcopenshell vs2022-x64 Release /p:Foo=bar`.
This behaviour is disabled now, because it doesn't allow validating provided args - it's impossible to tell whether `--config Release` is meant to be passed to msbuild or was meant as `--build-cfg Release` for `build-ifcopenshell`.
But it's still possible to pass args to msbuild by using `--` - `python build-ifcopenshell.py vs2022-x64 Release -- /p:Foo=bar`
`install-ifcopenshell.py` is now just a small wrapper passing `--target INSTALL` arg.
Moving to Python to make Windows build scripts more maintainable.
It's intended to be a drop-in replacement, so it should be possible to just switch `.\build-deps.cmd` to `python build-deps.py`, keeping exactly the same arguments and behaviour will be the same.
`build-deps.cmd` is deprecated, but not yet removed, but will be shortly after more testing.
Other batch files will be migrated to Python shortly after too.