Cmake updates

[mathstuf]

No description provided.

[partouf]

You will need to make a PR in our infra repo as well to add the new versions: https://github.com/compiler-explorer/infra/blob/main/bin/yaml/tools.yaml#L2

I would like to ask you however not to remove older versions here, so if you can add those back, please.

Concerning cmake-importstd. If it's not on here https://github.com/Kitware/CMake/releases we cannot install that version, and it might be best to just wait for the official build.

[mathstuf]

I would like to ask you however not to remove older versions here, so if you can add those back, please.

What about f5609fc?

I'll add comments about other work that needs done here.

Concerning cmake-importstd. If it's not on here https://github.com/Kitware/CMake/releases we cannot install that version, and it might be best to just wait for the official build.

The idea is to make https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9337 available for experimentation with import std. AIUI, experimental builds of toolchains are supported, so a CMake one didn't seem that far-fetched.

[mattgodbolt]

Thanks @mathstuf - in general we try not to remove old versions (we may have said it was OK before due to the limited users of cmakescript, sorry for mixed messages). If you really want the old versions gone, and don't mind that anyone who has bookmarked or saved a URL refering to the old one will get a broken link, we can remove them. But generally we keep things around for that reason.

[mathstuf]

Given the compatibility CMake aims for, maybe storing CMake versions in X.Y instead of X.Y.Z would make more sense? I can do that moving forward; I'll keep the existing versions there in the next update.

[mattgodbolt]

If you're happy with that approach, sure. The URLs will encode the id exactly as you specify it. We support .alias directives to point ids at different spots. Happy to merge this though.

[mattgodbolt]

What is this version?

[mathstuf]

This is a build of master prior to the 3.30 release. master uses the date in YYYYMMDD format as the patch number to ensure monotonicity of version numbers across history. I think a few days after this is better as it has some bug fixes.

[mattgodbolt]

Does that install in the regular way? I'll give it a quick go (and than can unrevert if so)

[mattgodbolt]

It doesn't install in the regular way:

2024-04-29 21:46:50,313 lib.ce_install  INFO     tools/cmake 3.29.2 is already installed, skipping
Installing tools/cmake 3.29.20240416
2024-04-29 21:46:50,514 lib.installation_context ERROR    Failed to fetch https://github.com/Kitware/CMake/releases/download/v3.29.20240416/cmake-3.29.20240416-Linux-x86_64.tar.gz: <Response [404]>

so... how does one install it? There are two parts to adding tools to CE: the installation and the config. The installation is handled in the infra PR (as linked below).

[mathstuf]

No, they don't get tags and releases. You can get the commits that bump the version number (effectively a "tag") with git log --first-parent --max-parents=1 --format=%H\ %cd origin/master.

[mattgodbolt]

Then we'll have to remove this. Or you'll need to make a PR to our infra repo that knows how to install these versions

[mattgodbolt]

Actually I am sorry I spoke too soon. I don't know what "cmake-importstd" is. I will have to revert - ping if we can help.

In the mean time I will update infra to install the versions I know about.

[mattgodbolt]

@mathstuf sorry for the merge-then-revert. I can help if you let me know where that newer cmake comes from.