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

Closed
curbhalb opened this Issue Aug 21, 2013 · 19 comments

Projects

None yet

7 participants

@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
Member
alloy commented Aug 21, 2013

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
Member
alloy commented Aug 22, 2013

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.

xcodescreensnapz001

@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
muccy commented Sep 4, 2013

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
Member

Indeed, good catch, thanks!

@fabiopelosin fabiopelosin reopened this Sep 4, 2013
@alloy
Member
alloy commented Sep 4, 2013

@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
Member
alloy commented Sep 4, 2013

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

@blakewatters blakewatters pushed a commit to blakewatters/CocoaPods that referenced this issue Sep 4, 2013
Blake Watters Add `--copy-links` argument to rsync invocation during Resource Bundl…
…e copying. refs CocoaPods/CocoaPods#1309

This ensures that destination files are copied into the application bundle instead of symbolic links preventing the creation of invalid apps during Archive.
14542d8
@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
berg commented Sep 4, 2013

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

@josmo josmo referenced this issue in apptentive/apptentive-ios Sep 4, 2013
Merged

New podspec to use source instead of Lib #47

@fabiopelosin
Member

Closed by #1329

@shir
shir commented Sep 17, 2013

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.

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