Bump the latest allowed glam version to 0.21

[expenses]

No description provided.

[repi]

thanks!

[eddyb]

  Error: Android NDK is not found. Please set the path to the Android NDK with $ANDROID_NDK_ROOT environment variable.

Did some Android-related change break our CI? (clearly not specific to this PR)

[repi]

filed a separate issue about the Android CI failing on main in #890.

So think we can just merge this as is

[MarijnS95]

FWIW glam simply made all these functions (from_array()/new()/splat()) const fn so you can also call a clean constructor directly nowadays:

Suggested change

	const MIE_K_COEFFICIENT: Vec3 = Vec3::from_array([0.686, 0.678, 0.666]);
	const MIE_V: f32 = 4.0;
	const MIE_ZENITH_LENGTH: f32 = 1.25e3;
	const NUM_MOLECULES: f32 = 2.542e25f32;
	const PRIMARIES: Vec3 = const_vec3!([6.8e-7f32, 5.5e-7f32, 4.5e-7f32]);
	const PRIMARIES: Vec3 = Vec3::from_array([6.8e-7f32, 5.5e-7f32, 4.5e-7f32]);
	const MIE_K_COEFFICIENT: Vec3 = Vec3::new(0.686, 0.678, 0.666);
	const MIE_V: f32 = 4.0;
	const MIE_ZENITH_LENGTH: f32 = 1.25e3;
	const NUM_MOLECULES: f32 = 2.542e25f32;
	const PRIMARIES: Vec3 = const_vec3!([6.8e-7f32, 5.5e-7f32, 4.5e-7f32]);
	const PRIMARIES: Vec3 = Vec3::new(6.8e-7f32, 5.5e-7f32, 4.5e-7f32);

(from_array() just calls Self::new(a[0], a[1], a[2]) under the hood)

[MarijnS95]

But is this still backwards-compatible with >=0.17?

[expenses]

Oh true, I don't think it is now. I'll change that.

[eddyb]

But is this still backwards-compatible with >=0.17?

I didn't say anything about that after figuring out myself, but basically it doesn't matter AFAICT, since this is an example shader, and it's going to use whatever we have in Cargo.lock.

Only spirv-std has to be careful to remain compatible with all the supported versions.

[MarijnS95]

@eddyb the more reason to change this into a single version and not bother with a version range? I guess the examples and spirv-std would have to be updated in parallel anyway?

[repi]

upgrading glam is a bit of work for us so we prefer to support a range so it can be a bit decoupled. but can support 0.20 & 0.21 in spirv-std.

this specific code change in the repo was in the examples and as Cargo.lock with this uses 0.21 that is fine to require 0.21. but spirv-std does need to support all the range, which we do not have CI verification on but generally has been working quite well before.

[expenses]

Oh true, I don't think it is now. I'll change that.

I'll leave it as-is then :)

[MarijnS95]

this specific code change in the repo was in the examples and as Cargo.lock with this uses 0.21 that is fine to require 0.21. but spirv-std does need to support all the range, which we do not have CI verification on but generally has been working quite well before.

Yeah so I think the examples should then reflect the minimal supported version, which automatically trickles down into Cargo.lock correctly without requiring to manually set/check/cargo update this Cargo.lock. That helps when someone tries -Zminimal-versions with the examples even if that's an unlikely use-case.

After all you can still leave the main spirv-std crate to represent a proper range, and test for backwards compatibility!

[fu5ha]

Agree with Marijn here I think

[fu5ha]

Agree with Marijn here I think

[expenses]

Okay, I reverted the changes so that the only one is the glam version range change.

After all you can still leave the main spirv-std crate to represent a proper range, and test for backwards compatibility!

Ideally, the glam version that's used in the examples would be the earliest allowed one (0.17.0) instead of the one in Cargo.lock (0.20.2). But this can be done later.