{tools}[GCCcore/14.3.0] fish v4.0.6

[Thyre]

(created using eb --new-pr)

Since fish 4.0, they switched to Rust as their programming language.
This also means that crates are used to build fish. However, there doesn't seem to be any EasyBlock for such cases (e.g. CargoCMake?). Since there is other software with the same issue already merged, we chose to keep CMakeMake here.

CC @mtar, who did the work in our JSC repository.

[github-actions]

Updated software fish-4.0.6-GCCcore-14.3.0.eb

Diff against fish-3.7.1-GCCcore-13.3.0.eb

easybuild/easyconfigs/f/fish/fish-3.7.1-GCCcore-13.3.0.eb

diff --git a/easybuild/easyconfigs/f/fish/fish-3.7.1-GCCcore-13.3.0.eb b/easybuild/easyconfigs/f/fish/fish-4.0.6-GCCcore-14.3.0.eb
index 0c7e084ac2..6822fc66bf 100644
--- a/easybuild/easyconfigs/f/fish/fish-3.7.1-GCCcore-13.3.0.eb
+++ b/easybuild/easyconfigs/f/fish/fish-4.0.6-GCCcore-14.3.0.eb
@@ -2,29 +2,32 @@ easyblock = 'CMakeMake'
 
 name = 'fish'
 
-version = '3.7.1'
+version = '4.0.6'
 
 homepage = 'https://fishshell.com/'
 description = """
 fish is a smart and user-friendly command line shell for Linux, macOS, and the rest of the family.
 """
 
-toolchain = {'name': 'GCCcore', 'version': '13.3.0'}
+toolchain = {'name': 'GCCcore', 'version': '14.3.0'}
 
 source_urls = ['https://github.com/fish-shell/fish-shell/releases/download/%(version)s/']
 sources = [SOURCELOWER_TAR_XZ]
-checksums = ['614c9f5643cd0799df391395fa6bbc3649427bb839722ce3b114d3bbc1a3b250']
+checksums = ['125d9ce0dd8a3704dc0782925df34f0208bffc42af5f34914449d14c34b5dae1']
 
 builddependencies = [
-    ('binutils', '2.42'),
-    ('CMake', '3.29.3')
+    ('binutils', '2.44'),
+    ('CMake', '4.0.3'),
+    ('Rust', '1.88.0')
 ]
 
 dependencies = [
+    ('PCRE2', '10.45'),
+    ('gettext', '0.25'),
     ('ncurses', '6.5'),
 ]
 
-configopts = '-DBUILD_DOCS=off '
+configopts = '-DBUILD_DOCS=OFF '
 
 sanity_check_paths = {
     'files': ['bin/fish'],

[Thyre]

Test report by @Thyre
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
ZAM054 - Linux Zorin OS 17, x86_64, 12th Gen Intel(R) Core(TM) i7-1260P, 1 x NVIDIA NVIDIA GeForce MX550, 580.65.06, Python 3.10.12
See https://gist.github.com/Thyre/b552ca06a6d57bd09b6fcd5a2bcbfdb0 for a full test report.

[Thyre]

@boegelbot please test @ jsc-zen3

[boegelbot]

@Thyre: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de

PR test command 'if [[ develop != 'develop' ]]; then EB_BRANCH=develop ./easybuild_develop.sh 2> /dev/null 1>&2; EB_PREFIX=/home/boegelbot/easybuild/develop source init_env_easybuild_develop.sh; fi; EB_PR=23907 EB_ARGS= EB_CONTAINER= EB_REPO=easybuild-easyconfigs EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_23907 --ntasks=8 ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 7979

Test results coming soon (I hope)...

Details

- notification for comment with ID 3307225367 processed

Message to humans: this is just bookkeeping information for me,
it is of no use to you (unless you think I have a bug, which I don't).

[Thyre]

Test report by @Thyre
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
jpbl-s01-03 - Linux RHEL 9.5, AArch64, ARM UNKNOWN (neoverse_v2), 1 x NVIDIA NVIDIA GH200 480GB, 570.133.20, Python 3.9.21
See https://gist.github.com/Thyre/172f6e3763d6f83835c272300ed6de47 for a full test report.

[boegelbot]

Test report by @boegelbot
FAILED
Build succeeded for 0 out of 1 (1 easyconfigs in total)
jsczen3c2.int.jsc-zen3.fz-juelich.de - Linux Rocky Linux 9.6, x86_64, AMD EPYC-Milan Processor (zen3), Python 3.9.21
See https://gist.github.com/boegelbot/45d444882225c8ac57fb9cbe71041641 for a full test report.

[Thyre]

Test report by @Thyre
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
jwlogin03.juwels - Linux Rocky Linux 9.6, x86_64, Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz, Python 3.9.21
See https://gist.github.com/Thyre/bf45ec89f60b5754093d4d71154084fa for a full test report.

[Thyre]

Test report by boegelbot
FAILED
Build succeeded for 0 out of 1 (1 easyconfigs in total)
jsczen3c2.int.jsc-zen3.fz-juelich.de - Linux Rocky Linux 9.6, x86_64, AMD EPYC-Milan Processor (zen3), Python 3.9.21
See https://gist.github.com/boegelbot/45d444882225c8ac57fb9cbe71041641 for a full test report.

Well... that's probably caused by not using the things we set in our Cargo EasyBlocks...
@Micket, @Flamefire Any elegant idea on how to continue here?

[Flamefire]

How far do we want to go? It looks like it is going to download Rust crates as it basically just uses CMake as a wrapper around cargo build --bin foo (multiple such calls) and for installation

We'll need a custom easyblock for that. We can either write one for fish or anticipate more such projects and write a CargoCMakeNinja easyblock combining parts of both. Likely YAGNI applies, so one for fish should suffice for now.

Or enhance the Cargo EasyBlock to support custom configure and build commands. But we do too much potentially useful stuff in the CMakeMake configure_step that I wouldn't choose this approach

[Thyre]

How far do we want to go? It looks like it is going to download Rust crates as it basically just uses CMake as a wrapper around cargo build --bin foo (multiple such calls) and for installation

We'll need a custom easyblock for that. We can either write one for fish or anticipate more such projects and write a CargoCMakeNinja easyblock combining parts of both. Likely YAGNI applies, so one for fish should suffice for now.

Or enhance the Cargo EasyBlock to support custom configure and build commands. But we do too much potentially useful stuff in the CMakeMake configure_step that I wouldn't choose this approach

There are other projects going in that direction, but I would also agree that this shouldn't come up too often. And even if it does at some point, we can still convert one of the EasyBlocks into a more generic one.

librsvg is another example for Rust being used in one of our "non-Cargo" EasyBlocks, but that uses Meson & Ninja. So I don't think its worth thinking about generic EasyBlocks yet.

From my tinkering a while back, I think we might need easybuilders/easybuild-easyblocks#3665 for fish as well. I don't remember the exact details anymore, only that I ran into weird issues with their cargo crates.

[Flamefire]

librsvg is another example for Rust being used in one of our "non-Cargo" EasyBlocks, but that uses Meson & Ninja. So I don't think its worth thinking about generic EasyBlocks yet.

Does that download crates during the build?

[Thyre]

librsvg is another example for Rust being used in one of our "non-Cargo" EasyBlocks, but that uses Meson & Ninja. So I don't think its worth thinking about generic EasyBlocks yet.

Does that download crates during the build?

Yes, an offline build fails:

warning: spurious network error (1 try remaining): [6] Could not resolve hostname (Could not resolve host: index.crates.io)  
Error: CliError { error: Some(failed to get `clap` as a dependency of package `ci v0.0.0 (/opt/EasyBuild/apps/build/librsvg/2.61.0/GCCcore-14.3.0/librsvg-2.61.0/ci)`

Caused by:
    0: download of cl/ap/clap failed
    1: failed to download from `https://index.crates.io/cl/ap/clap`
    2: [6] Could not resolve hostname (Could not resolve host: index.crates.io)), exit_code: 101 }
command: ['/opt/EasyBuild/apps/software/Rust/1.88.0-GCCcore-14.3.0/bin/cargo', 'cbuild', '--locked', '--prefix', '/opt/EasyBuild/apps/software/librsvg/2.61.0-GCCcore-14.3.0', '--libdir', '/opt/EasyBuild/apps/software/librsvg/2.61.0-GCCcore-14.3.0/lib', '--library-type', 'staticlib', '--manifest-path', '/opt/EasyBuild/apps/build/librsvg/2.61.0/GCCcore-14.3.0/librsvg-2.61.0/Cargo.toml', '--target-dir', '/opt/EasyBuild/apps/build/librsvg/2.61.0/GCCcore-14.3.0/easybuild_obj/target', '--features', 'pixbuf', '-p', 'librsvg-c'], env: {'CARGO_PROFILE_DEBUG_OPT_LEVEL': '2'}
Traceback (most recent call last):
  File "/opt/EasyBuild/apps/build/librsvg/2.61.0/GCCcore-14.3.0/librsvg-2.61.0/meson/cargo_wrapper.py", line 194, in <module>
    subprocess.run(cargo_cmd, env=env, check=True)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/EasyBuild/apps/software/Python/3.13.5-GCCcore-14.3.0/lib/python3.13/subprocess.py", line 577, in run
    raise CalledProcessError(retcode, process.args,
                             output=stdout, stderr=stderr)

[Micket]

#20718 (comment)

libavif is another potential troublemaker.

Hard to know exactly how it should be generalized here, but the nice part is that the stuff Cargo easyblock is pretty orthogonal to what most easyblocks do, so it's relatively easily combined.

[Flamefire]

the stuff Cargo easyblock is pretty orthogonal to what most easyblocks do,

Maybe this could be moved to the core easyblock in framework then and the behavior gets triggered when a crates easyconfig parameter is set. Because I agree with your comment

I don't want to make a bunch of extra easyblocks like "ConfigureMakeCargo" etc

[Micket]

Just some thoughts for a potential upcoming discussion:

Possible options:

1. we just make cargopythonpackage, cargocmakemake, cargomesonninja stuff
2. we have mesonninja, cmakemake, and the other standard ones inherit from cargo easyblock by default, i.e. the are all "CargoCMakeMake" easyblocks.
3. move crates into framework, i.e. part of the base easyblock. This is sort of the same as just making those specific easyblocks inherit Cargo easyblock though (except it not applies to all, automatically).

Dealing with framework is always much much more of a hassle, so i would probably suggest option 2. If there needs to be some specific cargo+cmake or cargo+meson thing happening there, then such code could be added.

Given how much we have had to fiddle with crates and such, I would strongly suggest we avoid adding any such specifics into framework at all cost.

This does rely on hoping that the nesting biuld tool isn't passing overriding config flags to cargo though; but to fix that I see no other option but to patch/sed on a per-case basis.

---

Just a general thought, but this isn't really all that specific to cargo; we have other nested build tools, and they all have the same issue; like pip calling cmake (configuremakepythonpackage, cmakepythonpackage), and there is no nice general way out of it.

[Flamefire]

Option 2 sounds good to me too. Note that MesonNinja does not inherit from CMake

This came up again at #24995