I think you added easybuild/easyconfigs/m/McStas/McStas-3.5.24-foss-2023a.eb from #22833 here as well by mistake, right?

Yes indeed that was a mistake - I'll fix that. Thanks for noticing! The two are very closely related and almost identical.

@boegelbot: please test @ jsc-zen3

@jfgrimm: 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=22834 EB_ARGS= EB_CONTAINER= EB_REPO=easybuild-easyconfigs EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_22834 --ntasks=8 ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 6301

Test results coming soon (I hope)...

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

relevant lines from the log file:

-- Looking for bison and flex
-- FLEX was not found.
CMake Error at cmake/Modules/InstallMCCODE.cmake:184 (message):
  Could not locate flex executable.
Call Stack (most recent call first):
  mcxtrace/CMakeLists.txt:16 (installMCCODE)

@boegelbot please test @ jsc-zen3

@jfgrimm: 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=22834 EB_ARGS= EB_CONTAINER= EB_REPO=easybuild-easyconfigs EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_22834 --ntasks=8 ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 6311

Test results coming soon (I hope)...

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

Test report by @Micket
FAILED
Build succeeded for 0 out of 1 (1 easyconfigs in total)
vera-icelake-build - Linux Rocky Linux 9.2, x86_64, Intel(R) Xeon(R) Silver 4316 CPU @ 2.30GHz, Python 3.9.18
See https://gist.github.com/Micket/fb75e3b0840f24abbf80f4600b376073 for a full test report.

Yeah - me bad. The ENSURE_MCPL-flag really means exactly to checkout a local version of MCPL, which is not useful since MCPL now has its own EC-file

I should really know exactly how McXtrace is built - I am one of the original authors in fact. This was a silly mistake.

To provide a bit more background. McXtrace is in essence a specialized c-code generator. When the generated code is to be compiled the mcpl-lib has to be linked. There's a python script in the distro that helps automate the process. To summarise: only in a late stage are the libs needed.

So the only important thing about MCPL w.r.t. McXtrace is that libmcpl.so is availalble on LD_LIBRARY_PATH?

That's almost enough - for it to work correctly in all cases it requires that the binary mcpl-config is available on the path as well.

Test report by @Crivella
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
crivella-desktop - Linux Ubuntu 22.04.5 LTS (Jammy Jellyfish), x86_64, 13th Gen Intel(R) Core(TM) i9-13900K (skylake), Python 3.11.13
See https://gist.github.com/Crivella/4f0a6aef4a8be1bca330dd5a8dc59f58 for a full test report.

From the configure step

-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    ENSURE_NCRYSTAL
    PYTHON_EXECUTABLE
    Python3_EXECUTABLE
    Python_EXECUTABLE


-- Build files have been written to: /home/crivella/.local/easybuild/build/McXtrace/3.5.24/foss-2023a/easybuild_obj

It seems ENSURE_NCRYSTAL is actually not being used. I guess because it is only recognized in case of BUILD_MCSTAS=ON https://github.com/mccode-dev/McCode/blob/3e365f4d3cb8b1f41edb2f47507339d724871794/CMakeLists.txt#L38C1-L45C8

I am unsure if we should keep it considering you have a separate PR for McStas

• {phys}[foss/2023a] McStas v3.6.1 #22833

(I guess we should also add a comment that McStas is built separately in easybuild to avoid people turning it on in the future without realizing it)

EDIT: an alternative might be to rename this to McCode and build both McXtrace and McStas together? Not sure if there was a reason they were originally split

Again a bit of background: McXtrace and McStas are very much similar and share some of the code base which is why they reside in the same repo. The former deals with X-rays, the latter with neutrons.
ncrystal is only valid for neutrons. (there's some talk of porting, but that project is not likely to happen in the foreseeable future).

Historically McStas is the older sibling, years later McXtrace was built as a port of it. Apart from some shared common code, they do not work together, and have always been considered two separate entities. The name mccode is almost exclusively used by the core development team.

All-in-all, there's a practical case for having a single EC-file, but I would not recommend it - very few people would recognize it.

Is it possible to maintain a single mccode EC-file, but with shallow McXtrace and McStas "virtual" EC-files that depend on it? EDIT: That'd be using the "bundle"-easyblock I suppose

@boegelbot please test @ jsc-zen3

Historically McStas is the older sibling, years later McXtrace was built as a port of it. Apart from some shared common code, they do not work together, and have always been considered two separate entities. The name mccode is almost exclusively used by the core development team.

Thanks for the info.
No need to overcomplicate it, my idea of merging them was because i thought they were 2 tools part of the same suite of code (as they are built through the same CMakeLists.txt).
If they are functionally separate I am fine keeping them split in EasyBuild

@Crivella: 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=22834 EB_ARGS= EB_CONTAINER= EB_REPO=easybuild-easyconfigs EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_22834 --ntasks=8 ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 7823

Test results coming soon (I hope)...

Test report by @boegelbot
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
jsczen3c1.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/90de5f713b3f0eeeb93d1bd407da2159 for a full test report.

None of the required changes have been applied?

Ah - apologies - yet another silly mistake. I thought I accepted the changes by clicking resolved. "I owe you a beer at the airport" as we say in DK,

@boegelbot please test @ jsc-zen3

@Crivella: 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=22834 EB_ARGS= EB_CONTAINER= EB_REPO=easybuild-easyconfigs EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_22834 --ntasks=8 ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 7827

Test results coming soon (I hope)...

Test report by @boegelbot
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
jsczen3c4.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/d7a1c0c7d1c2279751262d766c2acd07 for a full test report.

Going in, thanks @ebknudsen!

Thanks @Crivella! Much appreciated!