Skip to content

Exclude Windows-specific CCTZ source files in podspec - #2138

Open
aslam9691 wants to merge 1 commit into
abseil:masterfrom
aslam9691:fix_cocoapod_build_issue
Open

Exclude Windows-specific CCTZ source files in podspec#2138
aslam9691 wants to merge 1 commit into
abseil:masterfrom
aslam9691:fix_cocoapod_build_issue

Conversation

@aslam9691

Copy link
Copy Markdown

Summary

  • This PR excludes Windows-specific CCTZ source files (absl/time/internal/cctz/src/*_win.cc) in the generated abseil.podspec.

Description

  • The CCTZ time zone library in Abseil contains platform-specific source files like absl/time/internal/cctz/src/time_zone_name_win.cc intended only for Windows builds. When consuming Abseil via CocoaPods on Apple platforms (iOS, macOS, tvOS, watchOS, visionOS), these Windows-specific files are unnecessary and cause build errors.

End-to-End Build Test

  • Tested integration with CocoaPods client project (gRPC Sample on iOS Simulator arm64 and x86_64).
  • xcodebuild -project Pods.xcodeproj -target abseil passed with ** BUILD SUCCEEDED **.

@aslam9691
aslam9691 marked this pull request as ready for review August 25, 2026 10:03
srcs)
# Writes dependencies of this rule.
for dep in sorted(rule.deps):
if not dep.startswith("//absl/"):

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks unrelated to the problem being fixed. Can you explain it to me?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a dependency with a different prefix was passed to get_spec_name, it would fail the assertion and throw an AssertionError. for the safety added this check.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that actually happening? Is that preferred to a silent error?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not happening right now, I just added it defensively for edge cases. I originally thought skipping it was safer than crashing the script, but if you prefer an explicit assertion failure to catch bad inputs early, I am happy to remove this check.

@derekmauro derekmauro Aug 29, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, "defensive programming" is for defending against things outside of your control. Here the assertion is a good thing. We are checking our own invariants. An error would be our fault, and it is best to stop immediately with a loud error.

It also also a good rule not to make unrelated changes like this one.

Please revert this part of the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants