-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Cut short extension load cycles during precompilation #53112
Cut short extension load cycles during precompilation #53112
Conversation
This seems better than the status quo so we should try it out imo. |
Should this be backported to 1.10? |
3d2e2bd
to
0f075f1
Compare
@KristofferC I've made this a |
I guess we should add a test. Should be enough to generate |
80aef1e
to
33d9e2a
Compare
Not needed as we now skip cycles in extensions by not precompiling those extensions until loading time (where it somehow works) re. #53972 cc. @KristofferC |
Depends on
Builds on #53111
Fixes #53081
Cuts the cycle short and highlights when two or more extensions are each triggered during the precompilation of eachother, which causes a dependency cycle in nested precompilation that was seen in #53081.
Note if this is considered safe, the
@warn
s could just be@debug
s and the user doesn't need to be notified.i.e. on master this confusing error occurs, and it's actually coming from a double nested precompile worker precompiling
SymbolicsForwardDiffExt
but trying to loadSymbolicsPreallocationToolsExt
which the parent worker is in the process of precompilingWith this PR
The cycle issue being this strong dependency branch
triggers both of these Symbolics extensions without the need for any further packages present.
So they both get triggered during the precompilation job of the other one.
Note that
FillArraysPDMatsExt
doesn't error on master likeSymbolicsPreallocationToolsExt
does. Not sure why not.cc. @ChrisRackauckas