[glm] Bump to 2023-06-08 & fix usage

[xiaozhuai]

• Changes comply with the maintainer guide
• SHA512s are updated for each updated download
• The "supports" clause reflects platforms that may be fixed by this new version
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

1. Bump to 0.9.9.8+20230608. Since latest release (0.9.9.8) of glm is about 3 years ago, there have been many important fixes and improvements during this time.
2. Fix usage

[LilyWangLL]

Usage passed on x64-windows.

[BillyONeal]

Unfortunately for version precedence rules 0.9.9.8+20230608 == 0.9.9.8, as things after the + are the 'build metadata' and not relevant for purposes of ordering. See https://semver.org/#spec-item-10

@christophe-lunarg Any chance of glm doing a real release soon?

If upstream won't do a release I think we have no choice but to switch to version-date.

[xiaozhuai]

If upstream won't do a release I think we have no choice but to switch to version-date.

@BillyONeal
How about keep the version 0.9.9.8 and just increase port-version?

[BillyONeal]

@BillyONeal How about keep the version 0.9.9.8 and just increase port-version?

That would sort the right way. Do you think users would be 'surprised' at the changes they get since then? Has upstream indicated they are going for 'live at head'? If the changes since then aren't 'small bugfixes' then I think we should go version-date.

[dg0yt]

Do you think users would be 'surprised' at the changes they get since then?

Repology will say that vcpkg is lying about the version.

for version precedence rules 0.9.9.8+20230608 == 0.9.9.8

Then how about using 0.9.9.8+20230608 and increasing the port number?
(I guess the key difficulty is explaining this to the reviewers...)

[xiaozhuai]

Then how about using 0.9.9.8+20230608 and increasing the port number?

I vote this.

@BillyONeal @dg0yt

What's your opinion？

[xiaozhuai]

@BillyONeal @dg0yt
It looks like there is no interest upstream in releasing a new version, I've update this pr and switch to version-date

[dsa-t]

This update breaks our application (KiCad), because values in quaternions are stored differently compared to 0.9.9.8.

Order in 0.9.9.8: x, y, z, w
https://github.com/g-truc/glm/blob/0.9.9.8/glm/detail/type_quat.hpp#L48C31-L48C31

Order in 2023-06-08: w, x, y, z
https://github.com/g-truc/glm/blob/5c46b9c07008ae65cb81ab79cd677ecc1934b903/glm/detail/type_quat.hpp#L48C31-L48C31

Looks like glm should be updated again, with GLM_FORCE_QUAT_DATA_XYZW set to restore the order.

[xiaozhuai]

@dsa-t
Thanks for reporting this, I look into it, but there is nothing we should do with this port.
You can define GLM_FORCE_QUAT_DATA_WXYZ in your user project.

[dsa-t]

Another thing is, GLM_FORCE_QUAT_DATA_XYZW likely won't work properly before g-truc/glm@c660699

[xiaozhuai]

Another thing is, GLM_FORCE_QUAT_DATA_XYZW likely won't work properly before g-truc/glm@c660699

Yes, this port currently use g-truc/glm@5c46b9c, which is more later than g-truc/glm@c660699

[dsa-t]

Changes from g-truc/glm@c660699 aren't in g-truc/glm@5c46b9c.

See quat_cast, for example:
https://github.com/g-truc/glm/blob/5c46b9c07008ae65cb81ab79cd677ecc1934b903/glm/gtc/quaternion.inl#L81C31-L81C40

[xiaozhuai]

@dsa-t
Confirmed, I've submit a pr #34523 to fix it. Thanks for reporting.
BTW, the default behavior of GLM requires the users to define GLM_FORCE_QUAT_DATA_XYZW themselves, so vcpkg will not define it by default.