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
py-tensorflow: Update to version 2.12.0, Add Python 310 #15397
Conversation
Notifying maintainers: |
2ca3f5f
to
c52e1e0
Compare
Steve, I ran a quick local test on 10.15, to help validate whether the CI failures are legitimate. And sure enough, |
I only have access to macOS 12, and the build works. I expect that's an upstream issue that we'll never have much control over, or cycles to fix (per https://lists.macports.org/pipermail/macports-dev/2022-July/044443.html). I suggest just getting this thing running on the latest macOS and call it a day. If anyone requires bazel on older macOS version and knows how to fix it, or wants to download the binaries directly, they can issue a PR for an updated approach. |
Upstream offers three options to address old bazel version issues:
None of these are viable options at least with the resources I have. This supports adoption of the strategy laid out above:
|
cff82ec
to
c7a0975
Compare
Rebased against master. Also testing locally on 10.15, Big Sur, and Monterey, to see what the results are. More to follow. |
b3c71b5
to
0cef56c
Compare
0cef56c
to
fead933
Compare
fead933
to
62369ed
Compare
This now fails locally with the linker error: :info:build # Execution platform: @local_execution_config_platform//:platform
:info:build ld: malformed trie, childNodeOffset==0 file 'bazel-out/darwin-opt/bin/_solib_darwin_x86_64/_U_S_Stensorflow_Spython_C_Upywrap_Utensorflow_Uinternal_Umacos___Utensorflow_Spython/lib_pywrap_tensorflow_internal.dylib'
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build Error in child process '/usr/bin/xcrun'. 1 I'm throwing in the towel getting tensorflow built, and will split off the |
62369ed
to
32435d1
Compare
I'm fine with removing the older Python versions, but then add at least Python 3.11 which is MacPort's default |
That's going to require adding Python 3.11 support to a number of dependencies, which don't yet exist. So I don't think that's feasible for this update:
|
…onflict declarations
Okay, I'm finished with my cleanup, and I think we've done as much pre-testing as we can. Let's merge, and let the buildbots take on this update. |
The builds are failing very early in the process, for Monterey and Ventura Intel. (Still waiting to see whether it fails for Big Sur, as well as for ARM.) Though the errors are slightly different between them: |
Crap, it's also failing for ARM, albeit during the dependency installation phase. Hopefully this is easy to fix, as I thought (?) we had ARM support for some of our Java ports:
|
So, someone had broke java for arm? |
Hopefully not, this might simply be a bug/oversight in the Java portgroup. Need to investigate further. |
Seems that openjdk11-zulu wasn't build by Buildbot... |
Details for Monterey (paths trimmed to be relative, for readability):
Details for Ventura (again, paths trimmed to relative):
|
One bit of good news: So far, the Big Sur build is proceeding, without the failures seen for Monterey and Ventura. Hopefully it will succeed, keep your fingers crossed... |
I think that was intentional, though perhaps not ideal. Theoretically that shouldn't cause the issue though; I'm guessing the Java PG isn't finding the installation. |
On further review, it looks like the Java PG is working correctly, and pulling in Instead, it appears that Bazel (the project, not our port logic) isn't finding the JDK. Still digging... |
BTW I quite supprised that bazel doesn't build JDK from scratch. Seem that it something which they need to work on the next release :) |
Hmmmm... well, on the 2nd time around, the build for Monterey Intel didn't fail like it did before. So perhaps some upstream server was down, when files were being pulled? (Something in the realm of So there's hope that the Ventura Intel build might do the same. Fingers crossed... |
That’s pretty impressive you all got this and the |
Update: The builds for Bug Sur and Monterey almost complete successfully, but they fail at the very end with:
|
@mascguy I found the way to overstep that issue and it seems like insanity: https://stackoverflow.com/a/72494013 |
Yeah, I found that article too. Very interesting! During your research, did you see any definitive info, re: Which version of |
Insanity is part of the course as far as I am concerned when it comes to Bazel based builds... |
After taking an initial look at the documentation, and getting a better understanding of what it provides, etc, it seems like an incredibly powerful build tool! But with the caveat that the amount of functionality also requires a lot of learning. I'm not saying it's perfect by any means - nor am I advocating that we expand its use - but it does bring a lot to the table... |
I think that it is a kind of mistake to see bazel like a build tools. It is more like Docker or Nix which builds an application from different pieces. It can be used to build an application, but it is more general things.
The issue that it brings the table with it. The specific table which has more than one a kind of vendor lock-in to google. |
Description
Type(s)
Tested on
macOS 12.4 21F79 x86_64
Xcode 13.4.1 13F100
Verification
Have you
port lint --nitpick
?sudo port test
?sudo port -vst install
?