Use JULIA_CPU_TARGET

[visr]

Rather than the kwarg in JuliaC, let's try if using the environment variable JULIA_CPU_TARGET works better.

Related to #2644

The native binaries are for skylake-avx512. Most people including me don't have avx512, hence I get:

❯ ribasim.exe .\ribasim.toml
ERROR: Unable to find compatible target in cached code image.
Target 0 (skylake-avx512): Rejecting this target due to use of runtime-disabled features

[evetion]

I'm running a few personal builds on Teamcity using the main branch with different JULIA_CPU_TARGETs set as an env variable. Let's see what happens.

[visr]

Hmm on the latest commit the Windows Ribasim-API tests still fail with function 'jl_init_with_image_handle' not found, and running ribasim.exe locally gives:

thread 'main' panicked at src\main.rs:69:49:
called `Result::unwrap()` on an `Err` value: GetProcAddress { source: Os { code: 127, kind: Uncategorized, message: "The specified procedure could not be found." } }

Also curious that this takes much longer to compile on Windows, 100 minutes for the compile step.

[evetion]

On Teamcity you should

enable the Show all personal builds option under User Profile | General | UI settings.
to see my builds and download their artefacts.

Some patterns:

• Building for each new architecture increases the build time. Some experiments with the default flags and adding skylake-avx512 exceeded 2 hours on Windows.
• Linux and Windows differ significantly, Windows is easily twice as slow, and testing also differs.

On Teamcity Linux, this PR builds and all tests are green(!). On main, with setting JULIA_CPU_TARGET to generic or generic;native it builds and only the basic or basic_transient test fail with exitcode -11.

On Teamcity Windows, this PR fails horribly, Rust can't find the procedure, and neither can Python in the BMI tests (note that my last commit never touched the Python code, so that could be fair). On main, my personal JULIA_CPU_TARGET builds are green, and tests pass.

[visr]

Thanks, yes it seems a bit all over the place with possibly multiple bugs in JuliaC / PackageCompiler / julia.
JuliaC is currently not testing multiversioning at all so I thought JuliaLang/JuliaC.jl#47 would be a good start as it may bring them to light.

We can wait a little, but may need to start thinking about reverting stuff. Ideally only JuliaC -> PackageCompiler would be enough, but perhaps we need to go back to Julia 1.11 as well.

[evetion]

We can wait a little, but may need to start thinking about reverting stuff. Ideally only JuliaC -> PackageCompiler would be enough, but perhaps we need to go back to Julia 1.11 as well.

If we wait, we should use the old release/executable for the DSD. So no new features since then.

[visr]

I want to do a new release before the pizza course. I was thinking to wait max a week before reverting.

EDIT: reverted in 84c5182