rename dev-util/{cmake,ninja} to dev-build/{cmake,ninja} + also remove dev-build/meson

[bedroge]

Fixes #236.

The current 2026.06 installations do have these tools, so we may want to trigger a rebuild here to get them removed?

Edit: also added meson to the list.

[bedroge]

bot: build repo:eessi.io-2025.06-compat instance:eessi-bot-mc-aws for:arch=x86_64/generic

[eessi-bot-aws]

New job on instance eessi-bot-mc-aws for repository eessi.io-2025.06-compat
Building on: generic
Building for: x86_64/generic
Job dir: /project/def-users/SHARED/jobs/2026.07/pr_237/181639

date	job status	comment
Jul 30 08:58:06 UTC 2026	submitted	job id 181639 awaits release by job manager
Jul 30 08:58:19 UTC 2026	released	job awaits launch by Slurm scheduler
Jul 30 09:04:35 UTC 2026	running	job 181639 is running
Jul 30 10:35:36 UTC 2026	finished	😁 SUCCESS (click triangle for details) Details ✅ job output file slurm-181639.out ✅ no task failed ✅ found tarball Artefacts eessi-2026.06-compat-linux-x86_64-1785402840.tar.gz size: 1981 MiB (2077779643 bytes) entries: 201084
Jul 30 10:35:36 UTC 2026	test result	😢 FAILURE (click triangle for details) Reason Failed for unknown reason Details ✅ job output file slurm-181639.out ✅ no message matching ERROR: ✅ no message matching [\s*FAILED\s*].*Ran .* test case

[boegel]

The current 2026.06 installations do have these tools, so we may want to trigger a rebuild here to get them removed?

I think it would be good if the EESSI 2025.06 compat layer does not have cmake, ninja, and meson installed, that can only lead to problems imho...

That implies doing a full rebuild and re-deploy, right?

Can we come up with a way to avoid this in the future? Why didn't removing or filtering out non-existing packages lead to errors?

[bedroge]

I think it would be good if the EESSI 2025.06 compat layer does not have cmake, ninja, and meson installed, that can only lead to problems imho...

2026.06 or also 2025.06? I'd be a bit more reluctant to do it for 2025.06, since it could have been used by existing installations?

That implies doing a full rebuild and re-deploy, right?

Yes, unless we do some testing with an overlay first and carefully keep track of what needs to be changed/deleted. Then we could apply those changes on the Stratum 0. But I don't think we should do that.

Can we come up with a way to avoid this in the future?

I've added a test in this PR which should catch this next time: it checks if the list of tools is in the compat layer's $PATH.

Why didn't removing or filtering out non-existing packages lead to errors?

Ansible basically just checks if the given package name is installed, and if so, it removes it. In this case it was a package that doesn't exist anyway, so it happily reported that it was not installed...

[boegel]

I think it would be good if the EESSI 2025.06 compat layer does not have cmake, ninja, and meson installed, that can only lead to problems imho...

2026.06 or also 2025.06? I'd be a bit more reluctant to do it for 2025.06, since it could have been used by existing installations?

Sorry, I meant 2026.06, I don't see the value in doing it for EESSI 2025.06 at this point just to get rid of build tools like cmake...

That implies doing a full rebuild and re-deploy, right?

Yes, unless we do some testing with an overlay first and carefully keep track of what needs to be changed/deleted. Then we could apply those changes on the Stratum 0. But I don't think we should do that.

Doesn't seem worth the trouble for EESSI 2026.06, since nothing is built on top yet.

Can we come up with a way to avoid this in the future?

I've added a test in this PR which should catch this next time: it checks if the list of tools is in the compat layer's $PATH.

Overlooked that initially, thanks!

Why didn't removing or filtering out non-existing packages lead to errors?

Ansible basically just checks if the given package name is installed, and if so, it removes it. In this case it was a package that doesn't exist anyway, so it happily reported that it was not installed...