-
Notifications
You must be signed in to change notification settings - Fork 552
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
Separate libunwind into 1.3.2 and 1.5.0 builders, add a patch #3856
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, but I'd suggest to reorganise this a bit, to avoid duplication:
- have a file
L/LibUnwind/common.jl
with most variables defined there, in particular thescript
. We have plenty of similar setups for other Julia dependencies, like LLVM and OpenBLAS - create the 1.5.0 directory in a separate pull request, otherwise registration is going to fail because of merge conflicts, which are a mess to manually fix when involve different compat bounds.
I know this is an extra hassle now, but we'll make it way easier to add more versions later on.
azure-pipelines.yml
Outdated
else | ||
delay = Second(0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cherry-picked this in #3858, since this is blocking everything at the moment.
The current version being built is 1.5.0, so the files now live in `LibUnwind@1.5.0`.
7ca887b
to
ec220a0
Compare
Note: This PR was restructured to just be 1.5.0, and I'll be submitting a follow-up with 1.3.2. |
PR #3856 refactored the previous master into a builder specifically for libunwind v1.5.0. To avoid issues with automated JLL registration, it only did that version. This commit now adds a separate builder for v1.3.2, the version of libunwind currently in use by Julia. Note that to avoid said issues with registration, this commit does not refactor the other builder to use a common setup; that can be done separately to reduce duplication.
PR #3856 refactored the previous master into a builder specifically for libunwind v1.5.0. To avoid issues with automated JLL registration, it only did that version. This commit now adds a separate builder for v1.3.2, the version of libunwind currently in use by Julia. Note that to avoid said issues with registration, this commit does not refactor the other builder to use a common setup; that can be done separately to reduce duplication.
…ackaging#3856) * Move libunwind files to a versioned subdirectory The current version being built is 1.5.0, so the files now live in `LibUnwind@1.5.0`. * Add libunwind PR 308 as a patch
PR JuliaPackaging#3856 refactored the previous master into a builder specifically for libunwind v1.5.0. To avoid issues with automated JLL registration, it only did that version. This commit now adds a separate builder for v1.3.2, the version of libunwind currently in use by Julia. Note that to avoid said issues with registration, this commit does not refactor the other builder to use a common setup; that can be done separately to reduce duplication.
As of #3804, the libunwind builder builds v1.5.0. However, Julia still uses v1.3.2 (cf. JuliaLang/julia#42782). In order to fix JuliaLang/julia#41943 we'll need libunwind/libunwind#308, but that fix will also need to be backported. Thus it seems the path of least resistance is to add back the previous v1.3.2 builder (the contents of the L/LibUnwind directory prior to #3804) and create new JLL releases for both libunwind versions.