You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we are starting to actively use platform tags we might have the situation that someone runs
on a platform + tag combo that is not supported by the current _jll.
Situations in which that might arise:
New architectures like riscv
Microarchitectures
A new CUDA version
Library only build against some of the MPI implementations
A user wanting to load an old jll on a newer platform
In that situation loading the jll will fail and there are no products available to override using Preferences.jl
So now a user has to go through the effort of rebuilding all the artifacts etc. in Yggdrasil just to test their code.
Right now products are platform specific (and generally that's a really good thing), but maybe we need a "generic"/"default" platform that provides a minimum set of products that the user can provide through preferences.
The text was updated successfully, but these errors were encountered:
In that situation loading the jll will fail and there are no products available to override using Preferences.jl
The fundamental issue here is that we enter this branch and error out. Potential solution: allow some kind of user-configurable "default", but the method by which we do this is uncertain; products and whatnot can be completely platform-dependent, as Valentin pointed out above.
Right now products are platform specific (and generally that's a really good thing), but maybe we need a "generic"/"default" platform that provides a minimum set of products that the user can provide through preferences.
One potential way forward is to have BB analyze the set of products built across all platforms and automatically determine which are shared by all architectures. But there is still useful metadata that the user would be forced to provide, and I'm not sure this is actually that helpful.
Another potential way forward is to force users to dev the JLL, then just give them an easy way to generate a new wrapper file. We could even avoid "dev" part by having the path to the best wrapper script be overridable via a Preference. E.g. something like have best_wrapper check for a preference and only if it is missing, should it do the whole song and dance to load the artifacts.toml, search for a matching platform, etc... Then we just provide the user with a way to generate an appropriate wrapper file.
Now that we are starting to actively use platform tags we might have the situation that someone runs
on a platform + tag combo that is not supported by the current
_jll
.Situations in which that might arise:
riscv
jll
on a newer platformIn that situation loading the
jll
will fail and there are no products available to override using Preferences.jlSo now a user has to go through the effort of rebuilding all the artifacts etc. in Yggdrasil just to test their code.
Right now products are platform specific (and generally that's a really good thing), but maybe we need a "generic"/"default" platform that provides a minimum set of products that the user can provide through preferences.
The text was updated successfully, but these errors were encountered: