Pod build frameworks - #765
Merged
Merged
Conversation
…built. Fix case when builad pod as framework but pod consists of several specs
Summary - Extender code coverage reportSummary
Coveragecom/defold/extender - 26.4%
com/defold/extender/builders - 0%
com/defold/extender/cache - 35.4%
com/defold/extender/cache/info - 100%
com/defold/extender/log - 0%
com/defold/extender/metrics - 7.4%
com/defold/extender/process - 10.4%
com/defold/extender/remote - 0%
com/defold/extender/services - 23.9%
com/defold/extender/services/cocoapods - 50.3%
com/defold/extender/services/data - 80.7%
com/defold/extender/tracing - 0%
com/defold/extender/utils - 0%
|
britzl
approved these changes
Aug 22, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Added method to build Cocoapods dependencies as framework. Initially it should solve problem that Firebase libraries can't be built if
use_frameworks!flag is not used in Podfile.Technical details
Main
Now every Project can specify in its Podfile
use_frameworks!flags which we detect and added to the final Podfile used for dependency resolution. By defaultuse_frameworks == true for now because it was old behaviour and it can be changed after updating Firebase extensions with that flag During cocoapods dependency resolution we check isuse_frameworks!` is presented and have two code paths to build dependency: as static library or as framework.Framework build consist of:
-F<path_to_current_framework>. Additionally we pass generated VFS definition. It solves problem that compiler detect the same headers in different locations which leads to errors. VFS solves it. If framework has dependencies (defined in Pod spec) we merge generated GFS from that dependencies into current framework VFS (To be short, compiler will now where to find headers for dependencies).Virtual Filesystem (VFS) and Header maps
VFS overlay and Header maps are Apple private formats which used for compile-time optimizations. VFS is a list of mappings where files used for compilation (headers) are located in the real FS. Header map is the similar mappings but it defined where to find header for different include format ("" and <>). Header map is a binary format that's why for generation I used a third-party tool
hmap(installed from brew). Initially I generated headermap in json format and than convert it to binary. In headermap I include all public headers in 2 variants: "SomeHeader.h" and <SomeFramework/SomeHeader.h>. For private headers - only "" format. It solves problem when inside dependency code headers include differently - in one place via <>; in other - via "".Also those two files should helps to avoid excessive disk operation for searching headers and as a result - faster compilation.
Other notes
PodBuildSpec. These class contains all runtime-generated information which is needed for compilation.PodSpecnow contains only parsed from pod spec information, nothing else. AlsoPodBuildSpechas methods to add subspec if any of subspecs is defined in Podfile or during pod resolution. Now if several subspec are used they all accumulated (sources, resources, headers, flags) under one PodBuildSpec with name of main PodSpec. During the build we iterate and build PodBuildSpec (which can contains several subspec). It solves problem that several subspec should be united and presented as one static library inside framework (for example, KSCrash). When we built as static library - it doesn't matter are they separate libraries or not.// **********************) which updates compiler command for old versions ofbuild.ymlFixes #733