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

Comments

Projects
None yet
10 participants
@epologee

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

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Nov 5, 2013

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@fabiopelosin

fabiopelosin Nov 5, 2013

Member

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

Member

fabiopelosin commented Nov 5, 2013

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

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Nov 5, 2013

Member

Ah yeah, that’s an even better idea.

Member

alloy commented Nov 5, 2013

Ah yeah, that’s an even better idea.

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Nov 6, 2013

Member

@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!

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

This comment has been minimized.

Show comment
Hide comment
@fvvliet

fvvliet 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

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

This comment has been minimized.

Show comment
Hide comment
@n8chur

n8chur 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.

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

This comment has been minimized.

Show comment
Hide comment
@CocoaPodsBot

CocoaPodsBot Mar 29, 2014

Issue has been confirmed by @neonichu

CocoaPodsBot commented Mar 29, 2014

Issue has been confirmed by @neonichu

@jairobjunior

This comment has been minimized.

Show comment
Hide comment
@jairobjunior

jairobjunior Mar 30, 2014

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

jairobjunior commented Mar 30, 2014

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

@disaabler

This comment has been minimized.

Show comment
Hide comment
@disaabler

disaabler May 5, 2014

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.

disaabler commented May 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jpaas

jpaas 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}"

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

This comment has been minimized.

Show comment
Hide comment
@tchagnon

tchagnon Mar 21, 2015

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.

tchagnon commented Mar 21, 2015

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

[Copy Resources] Resolve various problems with xcasset bundles
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

[Copy Resources] Resolve various problems with xcasset bundles
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

[Copy Resources] Resolve various problems with xcasset bundles
Allow support for pods with xcasset bundles using `:path`.

Closes #1549
Closes #3384
Closes #3358

@kylef kylef closed this in #3405 Apr 15, 2015

kylef added a commit that referenced this issue Apr 16, 2015

[Copy Resources] Resolve various problems with xcasset bundles
Allow support for pods with xcasset bundles using `:path`.

Closes #1549
Closes #3384
Closes #3358

cbrauchli added a commit to cbrauchli/CocoaPods that referenced this issue Apr 21, 2015

[Copy Resources] Resolve various problems with xcasset bundles
Allow support for pods with xcasset bundles using `:path`.

Closes #1549
Closes #3384
Closes #3358
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment