@climbfuji You might want to look at some of the changes in spack#1782 as well. For example for yafyaml I had to add:

    # This is needed because for ifx 2025.2, we need to use cpp from GNU as fpp from oneapi
    # is broken. To pull that in, we need to say yafyaml depends on C, even though it really
    # doesn't.
    depends_on("c", when="^[email protected]", type="build")
    depends_on("gcc", when="^[email protected]", type="build")

because while yafyaml v1.6.0 has the fpp fix built into its CMake, it still needs the "external" cpp. I based this on what you did in spack#1592 for MAPL.

@climbfuji You might want to look at some of the changes in spack#1782 as well. For example for yafyaml I had to add:

    # This is needed because for ifx 2025.2, we need to use cpp from GNU as fpp from oneapi
    # is broken. To pull that in, we need to say yafyaml depends on C, even though it really
    # doesn't.
    depends_on("c", when="^[email protected]", type="build")
    depends_on("gcc", when="^[email protected]", type="build")

because while yafyaml v1.6.0 has the fpp fix built into its CMake, it still needs the "external" cpp. I based this on what you did in spack#1592 for MAPL.

If my upstream spack PR is no longer valid, then perhaps we should close it and use your PR instead? I can update the packages here from your upstream PR.

@climbfuji You might want to look at some of the changes in spack#1782 as well. For example for yafyaml I had to add:

    # This is needed because for ifx 2025.2, we need to use cpp from GNU as fpp from oneapi
    # is broken. To pull that in, we need to say yafyaml depends on C, even though it really
    # doesn't.
    depends_on("c", when="^[email protected]", type="build")
    depends_on("gcc", when="^[email protected]", type="build")

because while yafyaml v1.6.0 has the fpp fix built into its CMake, it still needs the "external" cpp. I based this on what you did in spack#1592 for MAPL.

If my upstream spack PR is no longer valid, then perhaps we should close it and use your PR instead? I can update the packages here from your upstream PR.

@mathomp4 Another option is to proceed with this PR as is for spack-stack-dev. We don't have yafyaml 1.6.0 anyway.

Then, we close my upstream PR and let your GFE packages update PR handle all the packages. Once your PR gets merged, we can update all the GFE packages by cherry-picking the squashed merge and (via conflict resolution) overwrite my changes in this PR.

But I can also do this now from your PR by cherry-picking all your commits (I can't pull your branch, because spack-stack-dev is currently behind develop).

What's your preference?

@climbfuji Oh yeah. I guess if you don't have yafyaml 1.6.0 it's sort of moot. So, yeah, stick with this and then when spack takes up the PRs in their repo, we can update here.