Skip to content
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

Getting .xcassets compilation to work for development pods? #1549

Closed
epologee opened this issue Nov 5, 2013 · 11 comments · Fixed by #3405
Closed

Getting .xcassets compilation to work for development pods? #1549

epologee opened this issue Nov 5, 2013 · 11 comments · Fixed by #3405
Labels
d3:hard An issue that is difficult to solve and may require significant changes s5:blocked t2:defect These are known bugs. The issue should also contain steps to reproduce. PRs welcome!

Comments

@epologee
Copy link

epologee commented Nov 5, 2013

The newly added compilation of a pod's xcassets uses the following shell script to find and compile any *.xcassets folder relative to the current (presumably the project's) directory:

if [ `find . -name '*.xcassets' | wc -l` -ne 0 ]
then
  DEVICE=`if [ "${TARGETED_DEVICE_FAMILY}" -eq 1 ]; then echo "iphone"; else echo "ipad"; fi`
  find "${PWD}" -name "*.xcassets" -print0 | xargs -0 actool --output-format human-readable-text --notices --warnings --platform "${PLATFORM_NAME}" --minimum-deployment-target "${IPHONEOS_DEPLOYMENT_TARGET}" --target-device "${DEVICE}" --compress-pngs --compile "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.${WRAPPER_EXTENSION}"
fi

When using development pods however, it's unlikely that they're in a subfolder of the project directory, rather you'll have them somewhere higher up your folder structure. There are two references to the current folder, one find . and one find "${PWD}".

Shouldn't this script accomodate for the case of development pods, somehow referencing the specs and subspecs of a project's dependencies?

@alloy
Copy link
Member

alloy commented Nov 5, 2013

Indeed, this is a bug.

Instead of passing one dir to find, we should pass in all the individual pod dirs so it will also work with local :path dirs.

@fabiopelosin
Copy link
Member

I think that we should leverage the list of the resources as generated by CocoaPods otherwise we might include non used xcassets files.

@alloy
Copy link
Member

alloy commented Nov 5, 2013

Ah yeah, that’s an even better idea.

@alloy
Copy link
Member

alloy commented Nov 6, 2013

@ryanwmarsh I have an email saying you replied to this ticket, but can’t find it here. Anyways, it’s just as well to do a separate PR for this. Whatever works best for you. Thanks for the work!

@fvvliet
Copy link

fvvliet commented Dec 4, 2013

This issue looks like my problem with cocoapods & asset catalogs : I have an XCode project with a few targets, each target has its own asset catalog. After using cocoapods 0.28 the app shows images from the wrong asset catalog so targets get built with the wrong asset catalog.

Any advice how to fix this ?
thanks

@n8chur
Copy link

n8chur commented Dec 11, 2013

@fvvliet Our current solution has been to delete the .xcasset folder that belongs to any target we are not building for. You have to actually delete the folder from the filesystem, removing it from the project is not enough.

KptainO added a commit to KptainO/Rebelle that referenced this issue Dec 17, 2013
@CocoaPodsBot
Copy link

Issue has been confirmed by @neonichu

@jairobjunior
Copy link

Is there any workaround solution for this? I am using 0.30.0 and I am still having the same problem.

@disaabler
Copy link

The workaround I've currently found to avoid compilation of all .xcassets in the project is to modify Pods-resources.sh to search recursively for *.xcassets not in the current directory (i.e. root project directory), but in ./Pods directory.

@jpaas
Copy link

jpaas commented May 9, 2014

Thanks for the tip on modifying Pods-resources.sh, but searching on ./Pods didn't work for me. I added a second path to the actool invocation using the path of my local cocoapod.

  find "../mylocalpod" "${PWD}" -name "*.xcassets" -print0 | xargs -0 actool --output-format human-readable-text --notices --warnings --platform "${PLATFORM_NAME}" --minimum-deployment-target "${IPHONEOS_DEPLOYMENT_TARGET}" ${TARGET_DEVICE_ARGS} --compress-pngs --compile "${BUILT_PRODUCTS_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}"

@tchagnon
Copy link

This appears to be fixed in master after 9cd9ce4

We had a post_install that twiddled Pods-resources.sh as a workaround for this. Since 0.36.0, there is no longer a find command for these resources, but the path is still broken until 9cd9ce4.

kylef added a commit that referenced this issue Apr 15, 2015
Allow support for pods with xcasset bundles using `:path`.

Closes #1549
Closes #3384
Closes #3358
kylef added a commit that referenced this issue Apr 15, 2015
Allow support for pods with xcasset bundles using `:path`.

Closes #1549
Closes #3384
Closes #3358
kylef added a commit that referenced this issue Apr 15, 2015
Allow support for pods with xcasset bundles using `:path`.

Closes #1549
Closes #3384
Closes #3358
kylef added a commit that referenced this issue Apr 16, 2015
Allow support for pods with xcasset bundles using `:path`.

Closes #1549
Closes #3384
Closes #3358
cbrauchli pushed a commit to cbrauchli/CocoaPods that referenced this issue Apr 21, 2015
Allow support for pods with xcasset bundles using `:path`.

Closes CocoaPods#1549
Closes CocoaPods#3384
Closes CocoaPods#3358
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
d3:hard An issue that is difficult to solve and may require significant changes s5:blocked t2:defect These are known bugs. The issue should also contain steps to reproduce. PRs welcome!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants