Part II of the Virtual File System Support (#70 continuation)
Problem:
When dynamic libraries are built in parallel, Xcode provides a mapping for virtual file system (-vfsoverlay argument) because some dependency files may not be ready yet, e.g. prepared .framework and compilers should look into "temporary" locations. Because these temporary locations are reported as dependencies, their absolute paths might leak to a meta json.
Solution
This PR inserts an extra step in the producer and consumer flows:
Producer: the overlay (assumed to be placed in $(TARGET_TEMP_DIR)/all-product-headers.yaml) replacement is performed for all recognized dependencies, before applying any ENV mappings (e.g. to substitute $(SRCROOT)) - a change to XCPostbuild
Consumer: the overlay (assumed to be placed in $(TARGET_TEMP_DIR)/all-product-headers.yaml) replacement is performed for all recognized dependencies, after applying any ENV mappings (e.g. to substitute $(SRCROOT)) - a change to XCPrebuild
Part II of the Virtual File System Support (#70 continuation)
Problem:
When dynamic libraries are built in parallel, Xcode provides a mapping for virtual file system (
-vfsoverlayargument) because some dependency files may not be ready yet, e.g. prepared.frameworkand compilers should look into "temporary" locations. Because these temporary locations are reported as dependencies, their absolute paths might leak to a meta json.Solution
This PR inserts an extra step in the producer and consumer flows:
$(TARGET_TEMP_DIR)/all-product-headers.yaml) replacement is performed for all recognized dependencies, before applying any ENV mappings (e.g. to substitute$(SRCROOT)) - a change toXCPostbuild$(TARGET_TEMP_DIR)/all-product-headers.yaml) replacement is performed for all recognized dependencies, after applying any ENV mappings (e.g. to substitute$(SRCROOT)) - a change toXCPrebuildFixes #59