Version support?

[dpo]

I'm trying to build binaries for a library that requires GSL v1. There's a build_tarballs.jl for v2.6 here, but my library won't build against it. What's the preferred solution? Should I vendor GSL v1 as part of my binaries, or open a pull request for, say, G/GSL1?

[staticfloat]

@giordano What do you think the best way to do this is? Ideally I'd like all the JLLs to be hosted within the same package, so that in your Project.toml file you can rely on GSL_jll and restrict it to versions 1 or 2 or whatever.

I'm thinking as far as Yggdrasil layout goes, we have at least the following options:

• Store in different subdirectories, e.g. G/GSL/1 and G/GSL/2?
• Since they may share many commonalities (E.g. similar patches across LLVM versions) we could put them in the same directory and support naming things more than just build_tarballs.jl? (e.g. G/GSL/[email protected]', G/GSL/[email protected]', etc...)
• Cram multiple build possibilities into build_tarballs.jl like we do for LLVMBootstrap or GCCBootstrap and teach CI how to figure out there are multiple versions within a file. I like this option least, and would honestly like to transition LLVMBootstrap and GCCBootstrap more towards using something else for "multi-versioning".

[giordano]

This is a though one. I agree that options 1 and 2 look better. In any case we need to teach azure pipelines how to deal with this. Maybe option 1 is the least disruptive, I think that adding one more level to the directory structure should be slightly easier than allowing for different file names for the builder scripts.

In the past I already wished having different levels, like for all Xorg packages, but that's not a big deal for the time being, so I never brought the idea up

[dpo]

Maybe build_tarballs.jl could take a --version argument that would make option 3 possible?

[giordano]

Interesting, but then doing CI would be hard, how would our system know which version to build for? Also, maybe you actually change the builder only for one of the two versions, but both are rebuilt, which is not ideal.

[dpo]

Yeah, sorry I don't appreciate the technical difficulties. There may be something to learn from systems like Spack, which supports different versions of packages.

[giordano]

They don't build for the users, the users build themselves, that's quite the opposite of what we do here.

[staticfloat]

Homebrew does essentially (2): they have ant and [email protected], for instance.

Arch does essentially (2) as well, they have llvm and llvm7.

We have an advantage here in that we have the flexibility to have multiple build_tarballs.jl files contain the same name within them; e.g. we can have L/LLVM7/build_tarballs.jl declare its name as LLVM and its version as v"7", but have L/LLVM8/build_tarballs.jl also declare its name as LLVM (only with a version of v"8"). This means that we'll get two LLVM_jll releases (one for each version) and that the resolver won't let a project use two different versions of LLVM at the same time. I like that a lot, and it's something that e.g. Homebrew has to worry about by declaring e.g. [email protected] as keg-only because it's versioned (meaning that they expect it to conflict with the normal ant formula, so they isolate it from the global search paths) but we get resolution for free. Huzzah!

So after thinking about this for a little bit, I have come to the decision that the easiest thing for us to do for now is to standardize on $(name)-v$(version.major) for multiversioned recipes. If you want to share code between multiple versions (looking at you, LLVM/GCC) we can do this with include("../$(name)-vX/common.jl") or something like that, and each build_tarballs.jl will declare their name to be the same so that they all apply to the same JLL package.

[giordano]

If in a commit we update the patch only for one version, how do we rebuild only that one?

[staticfloat]

I assume that version-specific patches would continue to only live in the "versioned" directories; e.g. L/LLVM7/bundled/patches/. If you were to modify a "shared" resources such as L/LLVM8/common.jl which is included by L/LLVM7/build_tarballs.jl then we will probably just as a policy require you to touch the L/LLVM7/build_tarballs.jl file to force a rebuild of both.

[staticfloat]

I kind of like GSL@1 better than GSL-v1. What do you guys think?

[giordano]

I think this is settled and the issue can be closed, right?