Resource Bundles created in pod spec via [spec].resource_bundle lack build configurations beyond 'debug' and 'release'

[curbhalb]

Pods that include resource bundles generated using the new "resource_bundle" function in the pod specs are missing the build configurations for the target that the library targets have.

I am using version 0.23.0.

For example, in my pod spec, I have

s.resource_bundle = { 'xxxDataService' => 'xxDataService/xxxDataService/Resources/.' }

When I "pod install" I look in my Pods project info, and I see

Configurations
Name Based On Configuration File

Release 2 Configurations Set
Debug 2 Configurations Set
Development 2 Configurations Set
Pods None
Pods-xxxDataService Pods-xxxDataService-Private
xxxDataService None
Pods Pods
...

In the target Pods-xxxDataService / Build Settings page, under Build Locations, I have

Per-configuration Build Products Path
AppStore
Debug
Development
QA
...

However, in the xxxDataService bundle target / Build Settings Page, under Build Locations, I have

Per-configuration Build Products Path
Debug
Release

Because of this, I can only ever build my project that includes this 'pod in a scheme that uses either Debug or Release, since any other will not put the xxxDataService.bundle file in the wrong location. Then, when the "Pods-resources.sh" script is ran, it returns a Code 23, because it was unable to find the file in the, for example, Development build configuration:

DerivedData/iPhone/Build/Products/Development-iphonesimulator/xxxDataService.bundle

[alloy]

Ouch, that’s a bug indeed.

I think this might be solved by #1294. Can you check if adding the configurations at the project level is enough to make it work?

[curbhalb]

Doesn't seem to, no. I added several different ones; they all appeared in the Build Configuratios in the library versions of the pods, but not the resource bundles.

[alloy]

Ok thanks for the feedback, this definitely needs some extra work then.

[blakewatters]

This is causing build failures during the Archive action during rsync execution when you have a Configuration called 'Distribution'. I tried adding the configuration specifier to the project via:

xcodeproj 'TAFlights', 'Distribution' => :release

The failure looks like:

/Users/blake/Library/Developer/Xcode/DerivedData/TAFlights-bkhzczvnybyyupaqrrhgtebffrvf/Build/Intermediates/ArchiveIntermediates/TAFlights/BuildProductsPath/Distribution-iphoneos/TAFlightsResources.bundle
building file list ... rsync: link_stat "/Users/blake/Library/Developer/Xcode/DerivedData/TAFlights-bkhzczvnybyyupaqrrhgtebffrvf/Build/Intermediates/ArchiveIntermediates/TAFlights/BuildProductsPath/Distribution-iphoneos/TAFlightsResources.bundle" failed: No such file or directory (2)
done
sent 29 bytes  received 20 bytes  98.00 bytes/sec
total size is 0  speedup is 0.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-42/rsync/main.c(992) [sender=2.6.9]
Command /bin/sh failed with exit code 23

Digging deeper into the directory structure, it looks like what's happening is the resources bundle symlink is winding up in /Users/blake/Library/Developer/Xcode/DerivedData/TAFlights-bkhzczvnybyyupaqrrhgtebffrvf/Build/Intermediates/ArchiveIntermediates/TAFlights/BuildProductsPath/Release-iphoneos/TAFlightsResources.bundle while all the other build assets are in /Users/blake/Library/Developer/Xcode/DerivedData/TAFlights-bkhzczvnybyyupaqrrhgtebffrvf/Build/Intermediates/ArchiveIntermediates/TAFlights/BuildProductsPath/Distribution-iphoneos

As soon as I get this archive built I'll take a peak in the code and see if I can't nail down a fix.

[blakewatters]

Unlike all the other targets in the Pods.xcodeproj have configuration set on them, but the resource bundles target does not. Attempting to set an xcconfig for the target causes it to be unselected immediately.

[blakewatters]

Man, there's a whole cluster of issues around Archiving + Resource Bundles. When I Archive the app against the Release configuration instead of Distribution the build succeeds, but Archive validation fails because the resources bundle is a symlink pointing outside of the app bundle:

warning: The binary is invalid.  A symbolic link resolves to a location outside of the binary.  
Relative location: TAFlights.app/TAFlightsResources.bundle resolves to: 
/Users/blake/Library/Developer/Xcode/DerivedData/TAFlights-bkhzczvnybyyupaqrrhgtebffrvf/Build/Intermediates/ArchiveIntermediates/TAFlights/IntermediateBuildFilesPath/UninstalledProducts/TAFlightsResources.bundle (-19056)Unable to validate your application. - (null)

[blakewatters]

Adding the -L or --copy-links option to the {Podname}-resources.sh script fixes this archive verification issue:

rsync -avr --copy-links --no-relative --exclude '*/.svn/*' --files-from="$RESOURCES_TO_COPY" / "${CONFIGURATION_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}"

[blakewatters]

@alloy is the addition of --copy-links a reasonable change based on your knowledge of this script's utility? In my use case there is only a single file being copied which is the resource bundle from a source symlink. It feels like there could be larger implications if there are cases where you actually want symlinks preserved within the destination bundle.

An alternative would either be to dereference the source file to its link target and append that to the list of files for rsync or perhaps the symlinked file path itself is the issue and it should be considering the target path.

[muccy]

You have closed the issue, but the problem @blakewatters reported is still there (I mean resource bundle not copied during archiving). Should we open a separate issue?
Thanks.

[fabiopelosin]

Indeed, good catch, thanks!

[alloy]

@blakewatters Thanks for investigating!

@alloy is the addition of --copy-links a reasonable change based on your knowledge of this script's utility? In my use case there is only a single file being copied which is the resource bundle from a source symlink. It feels like there could be larger implications if there are cases where you actually want symlinks preserved within the destination bundle.

This would break (OS X) frameworks, which use symlinks for versioning: bitstadium/HockeySDK-Mac#12 (comment).

/cc @ashtom

An alternative would either be to dereference the source file to its link target and append that to the list of files for rsync or perhaps the symlinked file path itself is the issue and it should be considering the target path.

Yeah, that sounds like a better idea. Did you test something like this yet?

[alloy]

@blakewatters @ashtom Oops, I was wrong, frameworks are handled separately, so that should not be a problem for resource bundles.

[blakewatters]

Pull request sent with the --copy-links change on #1329

@alloy and @irrationalfab I just updated to 0.24.0 and the behavior is now worse than in 0.23.0. The Copy Pods resources script now fails outright with a path for the resources bundle that does not exist. Will investigate and report back shortly.

[blakewatters]

@alloy and @irrationalfab drilled in further. My Pods_TAFlights-resources.sh script included the follow install_resource line:

install_resource "${TARGET_BUILD_DIR}/TAFlightsResources.bundle"

This was causing the path to expand to /Users/blake/Library/Developer/Xcode/DerivedData/TAMain-fyaujpjzinkxfzbttefishytmiuh/Build/Intermediates/ArchiveIntermediates/TADebug/InstallationBuildProductsLocation/Applications/TAFlightsResources.bundle, which is where the Archived app target is being built.

Changing it to:

install_resource "${BUILT_PRODUCTS_DIR}/TAFlightsResources.bundle"

Seems to do the trick. I am updating my earlier pull request and deploying a build onto device to make sure the whole process is happy.

[blakewatters]

Okay the combination of these changes has left me with a resource bundle setup that works flawlessly. I am able to build and archive across all configurations without any hiccups.

@irrationalfab Can you merge my changes, close this issue and tag 0.24.1? I think resource bundles will be in good shape from that point forward.

[berg]

Yes please! This one caused us to ship a nasty regression to the store (and uh, subsequently update our testing procedures... ;))

[fabiopelosin]

Closed by #1329

[shir]

I think minor release should be done with this fixes. I can't create a build without them (I have to change Pods-resource.sh manually)

[blakewatters]

I've been rolling forward very stable in a resource bundle heavy setup without issue with all of the fixes applied for 2 weeks now. I feel pretty confident that we are in a happy place with resource bundles now and should ship a point release with the fixes. The current production version is unusably broken.