Noticed a bad precedent while working on #12:
Whenever glam releases a new major version and you cargo update or generate a new lockfile or generate this template, cargo will choose the most up-to-date glam version for spirv-std. It's declaring >0.30.8, allowing you to use newer glam versions that may have breaking changes, so e.g. 0.32.0 does satisfy this constraint. But the templates specify 0.30.8, which causes cargo to add two glam versions: 0.32.0 for spirv-std and 0.30.10 for the template. Now glam requires that you either enable std or libm (or nostd-libm) as a feature, so the 0.30.10 version will fail to compile, since the template expects spirv-std to do the feature configuration.
Noticed a bad precedent while working on #12:
Whenever glam releases a new major version and you
cargo updateor generate a new lockfile or generate this template, cargo will choose the most up-to-date glam version forspirv-std. It's declaring>0.30.8, allowing you to use newer glam versions that may have breaking changes, so e.g.0.32.0does satisfy this constraint. But the templates specify0.30.8, which causes cargo to add two glam versions:0.32.0forspirv-stdand0.30.10for the template. Now glam requires that you either enablestdorlibm(ornostd-libm) as a feature, so the0.30.10version will fail to compile, since the template expectsspirv-stdto do the feature configuration.