Initialize global Base.PROGRAM_FILE correctly

[PatrickHaecker]

Julia 1.12 does not allow setting the global Base.PROGRAM_FILE from another module (probably Main) at program startup with the existing logic.

There probably is a reason why the logic is so complicated. But I currently can't see it. Therefore, just use the already initialized Julia to simply do the work in Julia for all Julia versions instead of hand-crafting solutions which adapt to the evolving C API in different Julia versions.

Fixes #1066

[PatrickHaecker]

This is one of the cases, where you think that everything must be much easier than everyone else thought. In my experience, these cases are typically followed by learning that it's much more complicated than you thought.

So could you, @KristofferC, please review this? If this should indeed be the solution, I would be happy to get a new release of PackageCompiler.jl soon, as currently it's not working with 1.12.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.21%. Comparing base (a9af8ed) to head (7c2219f).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1068   +/-   ##
=======================================
  Coverage   86.21%   86.21%           
=======================================
  Files           3        3           
  Lines         805      805           
=======================================
  Hits          694      694           
  Misses        111      111           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[KristofferC]

It used to be like that, but was removed in #649 due to:

Remove dependency on at-eval in main --- macros (and eventually maybe the whole front end) might not be available in the system image, so use weaker mechanisms to assign PROGRAM_FILE

So I think it would be best if we had a C-version of this. Not sure how hard that is.

[PatrickHaecker]

It at least looks to be hard for me. I'll try a bit more, but don't know whether this will lead somewhere.

Note (partially to myself): If we can't fix this, we can at least limit the fix of this PR to 1.12. Being able to get apps depending on including eval is still better than not being able to get any app with 1.12.

[KristofferC]

Yeah, that's fair.

[PatrickHaecker]

1.13 contains Core.declare_global which could be used to solve the problem with the C API, but this is not available in 1.12. It looks like adding Core.declare_global could be backported to 1.12, but at least for the moment this does not seem to be a path forward for PackageCompiler.jl.

1.12 could use jl_declare_global, but this is only available in julia_internal.h and we do not use this at all in PackageCompiler.jl AFAIK until now. The app loads it as a dynamic library, though, so we probably could start using it, but this would be a larger change and I am not sure whether it's worth the effort. My feeling is that everyone who wants to optimize regarding @eval probably goes towards --strip with 1.12 anyway.

Then there is a hint by @Keno how it might be solvable, which I do not understand (assigning to which field?), but which might be irrelevant as it uses jl_eval_string and it's unclear whether it would work without using that.

I prepared the targeted fix for 1.12. Whoever wants to improve on this can do so in a future PR. But for the moment with this PR PackageCompiler.jl is usable again with 1.12 for at least the majority of the users.

[KristofferC]

The

Failed to precompile MyApp [f943f3d7-887a-4ed5-b0c0-a1d6899aa8f5] to "/var/folders/q1/lmdr88vx1k90l53fxl9p8lwc0000gn/T/jl_V7emoc/compiled/v1.12/MyApp/jl_56M6Bi".
ERROR: LoadError: InitError: MethodError: no method matching __artifact_str(::Module, ::String, ::SubString{String}, ::String, ::Dict{String, Any}, ::Base.SHA1, ::Base.BinaryPlatforms.Platform, ::Val{Artifacts})
The applicable method may be too new: running in world age 30173, while current world is 30182.

Closest candidates are:
  __artifact_str(::Any, ::Any, ::Any, ::Any, ::Any, ::Any, ::Any, ::Val{LazyArtifacts}) where LazyArtifacts (method too new to be called from this world context.)

error is known and not from this PR.

[PatrickHaecker]

I wasn't sure whether the other errors are a problem, so I tested at least 1.12 locally both for master and for this PR on Julia 1.12.1.

This is the output:
PackageCompiler-master.txt
PackageCompiler-1_12_PROGRAM_FILE.txt

To be honest, I am still not sure. But at least it looks like this PR does not add any problem to 1.12.1. Additionally, there are no changes expected to any other released Julia version. Therefore, I think you can merge this, @KristofferC. But please double-check whether you see a blocker.