Adds CMake support for the 54638bfc10 change.
One thing to note, compared to makepanda, is that CMake doesn't automatically rebuild the file if this env var is changed.
Apparently a host of thirdparty packages currently get included by default, such as importlib.metadata -> toml -> numpy, and this is getting rather out of hand. The ignoreImports mechanism provides a way for us to flag certain imports as being optional dependencies.
Also added is various "builtins" imports in Python 2.7 (which are all under version checks and would otherwise lead to the PyPI "builtins" package being included, which would pull in "future", etc.)
This appears to be a regression from 0fe56bd0a9, but I can't be sure. Before this fix, repeated clicks of an object would cause the scaling handles to get larger and larger, until eventually causing NaN assertions.
This error occurs when a BoundingSphere with a large radius is scaled by an even larger radius such that the radius becomes infinite. In this case, the BoundingSphere should be properly marked as infinite so that it behaves properly (and doesn't cause other assertions down the line).
It's necessary to set PYTHONHASHSEED=0 as well as SOURCE_DATE_EPOCH for deterministic compilation, and moreover, the generated zip files do still have timestamps in them.
This causes a syntax error for unsupported Python versions, which prevents display of the error message that tells people they are using a too-old Python version
Setting SOURCE_DATE_EPOCH to a UNIX timestamp will clamp all dates to that, which enables bit-for-bit recreation of wheel files (assuming the sources are also bit-for-bit identical). Furthermore, files are sorted when added, to avoid filesystem indeterminism.
* Use nearly-zero test to check which edges to snap the interior/surface points to, if any, to be less sensitive to fp precision
* The respect-prev-transform test now tests for a sphere that fits inside the box, to prevent a false positive test when the box has been rotated since the last test
* More appropriate surface point for respect-prev-transform test
Currently, all tests I'm aware of put the surface point above the interior point (ie. along the normal), but there seems to be no good reason for this requirement, especially since a dot product is more efficient than a length().
This avoids the need for the global mutex lock and allows two egg files to be read simultaneously.
Error reporting has also been improved by specifically pinpointing the offending token when an error occurs.
rdb