-
-
Notifications
You must be signed in to change notification settings - Fork 35
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 missing pin to libcxx-devel; fix libcxx run-export #315
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
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.
@isuruf, so it turns out that adding a version pin on libcxx-devel
runs into a bunch of issues:
- it conflicts with
libcxx {{ cxx_compiler_version }}
host pins (for packages depending onclangxx
) - it would cause a bootstrap issue because we don't have libcxx X+1 when we first build clangdev X+1
The bootstrapping I think I solved with a174f3a, but for the first issue I'm not 100% sure.
I think we could loosen the libcxx pins to build here, but not 100% sure why those were there in the first place.
recipe/meta.yaml
Outdated
# Use the same requirements as the top-level requirements | ||
- libcxx-devel {{ cxx_compiler_version }} # [osx] | ||
- libcxx-devel # [osx] |
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 would have expected the "use same as top-level" to have something to do with having the same hash of the host environment and maybe not busting the cache to rebuild things unnecessarily; however, I'm not sure from 91ad7d6 resp. ac155e5 if that's actually the case? I've removed it now to try and see.
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 should probably update the comment # Use the same requirements as the top-level requirements
for these outputs, but since I don't know/understand the original reason, I can only remove them. If you have input on this, please let me know.
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.
Tentatively updating the comment now to be
# unpinned because we depend on clangxx here, which pins libcxx-devel
If we want to keep everything on the same libcxx version, we could go one step further and pin everything to {{ version }}
, now that we're building libcxx
before clangdev
.
Ah, thanks. OK, I was waiting for your feedback on that PR (and thought we'd want to fix the compilers first). |
I merged conda-forge/libcxx-feedstock#192, which is the backport that's relevant here, as our However, this is still not enough, because now that we want That particular problem should be solvable by reinstating the commit (1ab6b2d) I had before for loosening the Whether we put the version pin in |
Even better, I tried building |
this does not seem necessary to build, and prevents us from letting `clangxx` depend on `libcxx-devel` (because it would create a build cycle); see conda-forge/clangdev-feedstock#315 (comment)
This and conda-forge/libcxx-feedstock#190 are now passing, and I believe should cover all bases, including the bootstrapping case. PTAL @isuruf |
Gentle ping @isuruf |
If you have some input on the thread above, please let me know. :) |
Alright putting this in for now, but happy to iterate further on the upcoming PRs for 19.1.0.rc4 & then 19.1.0 |
Oversight in #311, see here