Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add preferences overloading #27

Merged
merged 8 commits into from
Jan 19, 2021
Merged

Add preferences overloading #27

merged 8 commits into from
Jan 19, 2021

Conversation

staticfloat
Copy link
Member

This makes use of Preferences.jl to allow overriding of the paths of products. This is necessary for JLLWrappers being used in v1.7 (so that we can service USE_BINARYBUILDER_XXX=1 more easily, and also so that we can service USE_SYSTEM_XXX=1), as well as for the Spack work.

This adds a `@load_preferences()` lookup that defaults to the
artifact-local location for products, but can be overridden to arbitrary
paths, including system-wide searches by writing out just the SONAME of
the desired library.
User code (such as `BinaryBuilder`) needs to generate JLLs that have
`Preferences` as a dependency.
Copy link
Member

@giordano giordano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, but compatibility with Julia v1.5- looks a bit problematic

@@ -58,10 +58,11 @@ macro declare_executable_product(product_name)
end

macro init_executable_product(product_name, product_path)
preference_name = string(product_name, "_path")
path_name = Symbol(string(product_name, "_path"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this can be

Suggested change
path_name = Symbol(string(product_name, "_path"))
path_name = Symbol(preference_name)

to ensure consistency?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that; but I'm not entirely sure I want the preference name to be libfoo_path; perhaps just libfoo is better? What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, good point. For the preference the _path is probably redundant

src/toplevel_generators.jl Show resolved Hide resolved
test/runtests.jl Outdated Show resolved Hide resolved
@giordano
Copy link
Member

Did you measure impact on loading performance, for example for GTK3_jll?

src/wrapper_generators.jl Outdated Show resolved Hide resolved
src/wrapper_generators.jl Outdated Show resolved Hide resolved
@staticfloat
Copy link
Member Author

Did you measure impact on loading performance, for example for GTK3_jll?

Not yet; definitely something that needs doing; also I need to ensure that these operations are happening at the desired time (compile time, not runtime).

I decided that having `_path` on the end of preferences is a smart idea,
so that we can do other things like `_dlflags` or something in the
future.
Previously, we were loading preferences within `__init__()`; move it out
to top-level statements so that the preferences are loaded at compile
time and baked into the `.ji` files.
@staticfloat
Copy link
Member Author

I did the performance comparison; no measurable performance impact as long as the work is done at compile-time, which I have verified with the latest update!

@giordano
Copy link
Member

I'd say the failure on nightly is unrelated, but I don't really understand what's the failure at all:

JLLWrappers.jl: Error During Test at /home/runner/work/JLLWrappers.jl/JLLWrappers.jl/test/runtests.jl:11
  Got exception outside of a @test
  Failed to precompile Vulkan_Headers_jll [8d446b21-f3ad-5576-a034-752265b9b6f9] to /home/runner/.julia/compiled/v1.7/Vulkan_Headers_jll/jl_5SHlbR.
  Stacktrace:
    [1] error(s::String)
      @ Base ./error.jl:33
    [2] compilecache(pkg::Base.PkgId, path::String, internal_stderr::IOStream, internal_stdout::IOContext{Base.PipeEndpoint})
      @ Base ./loading.jl:1356
    [3] compilecache(pkg::Base.PkgId, path::String)
      @ Base ./loading.jl:1302
    [4] _require(pkg::Base.PkgId)
      @ Base ./loading.jl:1017
    [5] require(uuidkey::Base.PkgId)
      @ Base ./loading.jl:910
    [6] require(into::Module, mod::Symbol)
      @ Base ./loading.jl:897
    [7] eval
      @ ./boot.jl:369 [inlined]
    [8] (::var"#3#10")()
      @ Main /buildworker/worker/package_linux32/build/usr/share/julia/stdlib/v1.7/Test/src/Test.jl:669
    [9] (::Base.redirect_stdio)(thunk::var"#3#10", stream::IOStream)
      @ Base ./stream.jl:1240
   [10] #2
      @ /buildworker/worker/package_linux32/build/usr/share/julia/stdlib/v1.7/Test/src/Test.jl:668 [inlined]
   [11] open(::var"#2#9", ::String, ::Vararg{String}; kwargs::Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
      @ Base ./io.jl:330
   [12] open
      @ ./io.jl:328 [inlined]
   [13] macro expansion
      @ /buildworker/worker/package_linux32/build/usr/share/julia/stdlib/v1.7/Test/src/Test.jl:667 [inlined]
   [14] (::var"#1#8")(dir::String)
      @ Main ~/work/JLLWrappers.jl/JLLWrappers.jl/test/runtests.jl:24
   [15] mktempdir(fn::var"#1#8", parent::String; prefix::String)
      @ Base.Filesystem ./file.jl:732
   [16] mktempdir(fn::Function, parent::String)
      @ Base.Filesystem ./file.jl:730
   [17] macro expansion
      @ ~/work/JLLWrappers.jl/JLLWrappers.jl/test/runtests.jl:12 [inlined]
   [18] macro expansion
      @ /buildworker/worker/package_linux32/build/usr/share/julia/stdlib/v1.7/Test/src/Test.jl:1152 [inlined]
   [19] top-level scope
      @ ~/work/JLLWrappers.jl/JLLWrappers.jl/test/runtests.jl:12
   [20] include(fname::String)
      @ Base.MainInclude ./client.jl:451
   [21] top-level scope
      @ none:6
   [22] eval
      @ ./boot.jl:369 [inlined]
   [23] exec_options(opts::Base.JLOptions)
      @ Base ./client.jl:268
   [24] _start()
      @ Base ./client.jl:492

BTW, maybe we should run tests on Julia v1.6 now. The syntax in GitHub Actions should be ^1.6.0-0

@staticfloat
Copy link
Member Author

It's on 32-bit only; I'll try to reproduce

@staticfloat
Copy link
Member Author

X-ref: JuliaLang/julia#39274

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants