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
It would be nice if packages ship with a default ext.jl file which just worked if the user already had the dependencies. The hinderance to this appears to be the convoluted way in which the ext.jl file is generated: it uses a macro to do the runtime dlopen check. https://github.com/JuliaLang/BinDeps.jl/blob/master/src/dependencies.jl#L477
Instead, I propose the following template for ext.jl. ext_paths.jl would be auto-generated and would return the set of paths that BinDeps wants to search:
That link to the problematic macro is out of date (not surprising, since this was filed in January). @vtjnash, just so the rest of us can understand, can you edit it using y to get a permalink to a particular version of the file?
It would be nice if packages ship with a default ext.jl file which
just worked
if the user already had the dependencies. The hinderance to this appears to be the convoluted way in which the ext.jl file is generated: it uses a macro to do the runtime dlopen check.https://github.com/JuliaLang/BinDeps.jl/blob/master/src/dependencies.jl#L477
Instead, I propose the following template for
ext.jl
.ext_paths.jl
would be auto-generated and would return the set of paths that BinDeps wants to search:This still assumes that the runtime name/location of the file is mostly constant, but it also allows some runtime determination and checking.
The text was updated successfully, but these errors were encountered: