-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Shorten CMake Objective-C targets #5323
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
Conversation
These become visible once flags are handled uniformly across all Firestore targets in an upcoming build change.
CMake has built-in support for building Framework bundles (briefly: bundles of libraries, associated headers, and resources) but this doesn't work well for our needs. 1. In CMake 3.5.1 (our earliest supported CMake version) it doesn't copy headers properly at build time. 2. Even up to CMake 3.15.5, CMake doesn't handle link-line multiplicity correctly. CMake passes the static library location within the framework and this seems to cause the linker to mishandle Objective-C metaclass information resulting in duplicate symbols. Building with `-framework` flags works correctly. Previously we partially worked around the latter problem by building some frameworks as shared instead of static frameworks, but this is problematic because this mode of operation isn't actually intended and is unsupported as far as the rest of Firebase is concerned. This turned out to be fragile though and while refactoring libraries this workaround broke. Rather than piling on additional workarounds, this change converts the frameworks to simple library targets and emulates framework imports through include paths. Additionally, this starts refactoring our cmake helper functions to make them more like built-in functions. This makes it possible to freely use different CMake features that were made difficult by trying to wrap everything up in a single CMake command.
... making them more like built-in functions. This makes it possible to combine other CMake functions in ways that weren't possible with the original all-in-one approach. This includes: * firebase_ios_add_executable * firebase_ios_add_test * firebase_ios_add_library All of which can be combined with target_link_libraries, etc.
... and migrate it to new CMake primitives.
... and migrate to firebase_ios_add_test
... and migrate to firebase_ios_add_test.
... and migrate to firebase_ios_add_test.
... and migrate to firebase_ios_add_test.
... and migrate to firebase_ios_add_test.
Rename * firebase_firestore_protos_nanopb => firestore_protos_nanopb * firebase_firestore_protos_libprotobuf => firestore_protos_protobuf Also delete dead code in Firestore/Protos/CMakeLists.txt
... and migrate to firebase_ios_add_library.
... and: * migrate to firebase_ios_add_test * use globs to find sources
... and: * migrate to firebase_ios_add_test * use globs to find sources
... and: * migrate to firebase_ios_add_test * use globs to find sources
... and: * migrate to firebase_ios_add_test * use globs to find sources
... and: * migrate to firebase_ios_add_test * use globs to find sources * shorten firebase_firestore_remote_testing too
... and: * migrate to firebase_ios_add_test * collapse all tests down into just firestore_util_test
Now that we're committed to using globs for finding sources, this check is incompatible and no longer useful.
... and: * Migrate to firebase_ios_add_executable * Use globs for specifying sources
Rename firebase_firestore_objc_test_util to firestore_objc_testing.
Rewrite firebase_ios_cc_fuzz_test to match the other primitives.
Generated by 🚫 Danger |
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.
LGTM. Just a few comments about the usage of FIREBASE_IOS_BUILD_TESTS
.
firebase_firestore_objc_test_util | ||
) | ||
endif(APPLE) | ||
if(NOT FIREBASE_IOS_BUILD_TESTS OR NOT APPLE) |
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.
Testing the value of FIREBASE_IOS_BUILD_TESTS
and APPLE
is different from the original file, which only tested APPLE
. Can you confirm that this is an intended change?
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.
Great question. Sorry, I should have added a comment about this to the PR.
Previously, when using firebase_ios_objc_test
, that command could check FIREBASE_IOS_BUILD_TESTS
for itself and omit setting up the target because the command was (essentially) self-contained.
Now that I've switched us to using an arrangement where multiple commands are used to build up a target, it's no longer possible to usefully check for FIREBASE_IOS_BUILD_TESTS
in a command like firebase_ios_add_objc_test
. The problem is that if we omit the target, subsequent commands like target_link_libraries
will fail if the target doesn't exist. That means we have to check outside firebase_ios_add_objc_test
, and checking at the file level makes sense because this isn't necessarily uniform (though it is for this PR).
WORKING_DIRECTORY ${PROJECT_BINARY_DIR} | ||
) | ||
endif(APPLE) | ||
if(NOT FIREBASE_IOS_BUILD_TESTS OR NOT APPLE) |
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.
Same here... please confirm that checking FIREBASE_IOS_BUILD_TESTS
is indeed intended.
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.
This one's correct.
@@ -16,26 +16,17 @@ if(NOT APPLE) | |||
return() |
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.
Should FIREBASE_IOS_BUILD_TESTS
be checked in this file as well?
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.
Yes! Fixed.
* Shorten firebase_firestore_example_app ... and: * Migrate to firebase_ios_add_executable * Use globs for specifying sources * Migrate Example/Tests/API to new CMake primitives * Migrate Example/Tests/Integration to new CMake primitives * Migrate Example/Tests/SpecTests to new CMake primitives * Migrate Example/Tests/Util to new CMake primitives Rename firebase_firestore_objc_test_util to firestore_objc_testing. * Migrate fuzzing to new CMake primitives Rewrite firebase_ios_cc_fuzz_test to match the other primitives. * Add firebase_ios_add_objc_test * Migrate Example/Benchmarks to new CMake primitives
* Shorten firebase_firestore_example_app ... and: * Migrate to firebase_ios_add_executable * Use globs for specifying sources * Migrate Example/Tests/API to new CMake primitives * Migrate Example/Tests/Integration to new CMake primitives * Migrate Example/Tests/SpecTests to new CMake primitives * Migrate Example/Tests/Util to new CMake primitives Rename firebase_firestore_objc_test_util to firestore_objc_testing. * Migrate fuzzing to new CMake primitives Rewrite firebase_ios_cc_fuzz_test to match the other primitives. * Add firebase_ios_add_objc_test * Migrate Example/Benchmarks to new CMake primitives
This is a continuation of the work in #5321, renaming Objective-C and other nonessential targets from the point of view of the Windows build to match the pattern set out there.
The intent is that targets with a
firestore_objc_
prefix are built from Firestore/Sources and Firestore/Example. Those directories will eventually move to into Firestore/ObjC (see go/firestore-spm for details). This PR anticipates that move.