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

Pods copy resource script overrides default xcasset bahaviour #1546

Closed
barksten opened this Issue Nov 5, 2013 · 84 comments

Comments

Projects
None yet
@barksten

barksten commented Nov 5, 2013

I have a project with different "themes" that are used for different xcode targets. For the themes I have two xcasset catalogs, one with red graphics and one with green graphics. Inside the bundles the files are named the same (so that I can simply use background.png as image name and get the correct color). Which xcasset that get copied is determined by the target membership (and ultimately by the build step "copy bundle resources").
Since cocoa pods version 0.27 I've noticed that there is a new entry in the copy pods resource script. That will cause my red graphics copied by the standard xcode build step to be replaced with the green graphics copied by the cocoa pods copy resources build step.

@barksten

This comment has been minimized.

Show comment
Hide comment
@barksten

barksten Nov 5, 2013

I can add that as a workaround I just reordered the build steps so that the cocoa pods resources gets copied before the standard xcode build step. That way I get my target dependent resources copied last.

barksten commented Nov 5, 2013

I can add that as a workaround I just reordered the build steps so that the cocoa pods resources gets copied before the standard xcode build step. That way I get my target dependent resources copied last.

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Nov 5, 2013

Member

That’s very unfortunate. Are you even using pods that have asset catalogs?

@ulrikdamm Any ideas on how to improve this?

Member

alloy commented Nov 5, 2013

That’s very unfortunate. Are you even using pods that have asset catalogs?

@ulrikdamm Any ideas on how to improve this?

@ulrikdamm

This comment has been minimized.

Show comment
Hide comment
@ulrikdamm

ulrikdamm Nov 5, 2013

Contributor

If there is a way to read what files are copied in the copy bundle resources build step, then we could just pick those asset catalogs when building our own. Right now it just looks for xcassets files in the source directory.

Contributor

ulrikdamm commented Nov 5, 2013

If there is a way to read what files are copied in the copy bundle resources build step, then we could just pick those asset catalogs when building our own. Right now it just looks for xcassets files in the source directory.

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Nov 6, 2013

Member

Hmm, that’s probably going to be complex. I’ll have to mull this over.

Member

alloy commented Nov 6, 2013

Hmm, that’s probably going to be complex. I’ll have to mull this over.

@jonhocking

This comment has been minimized.

Show comment
Hide comment
@jonhocking

jonhocking Nov 14, 2013

Also seeing this with a similar project setup, and appreciate how hard it is to fix. If you need an example project or any more info, then I'd be happy to send something over.

jonhocking commented Nov 14, 2013

Also seeing this with a similar project setup, and appreciate how hard it is to fix. If you need an example project or any more info, then I'd be happy to send something over.

@luisobo

This comment has been minimized.

Show comment
Hide comment
@luisobo

luisobo Nov 27, 2013

Same issue here.

luisobo commented Nov 27, 2013

Same issue here.

@nitinkurian

This comment has been minimized.

Show comment
Hide comment
@nitinkurian

nitinkurian Dec 6, 2013

Facing the same issue. Has there been a resolution yet on this issue.

nitinkurian commented Dec 6, 2013

Facing the same issue. Has there been a resolution yet on this issue.

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Dec 10, 2013

Member

Alas not. I think one of you (or others with the same issue) will have to sit down and spend some time playing with Xcode to see if you can find a pragmatic solution that works regardless of CocoaPods.

Member

alloy commented Dec 10, 2013

Alas not. I think one of you (or others with the same issue) will have to sit down and spend some time playing with Xcode to see if you can find a pragmatic solution that works regardless of CocoaPods.

@n8chur

This comment has been minimized.

Show comment
Hide comment
@n8chur

n8chur Dec 11, 2013

I am having the same issue. Our current solution has been to delete the .xcasset folder that belongs to any target we are not building for.

n8chur commented Dec 11, 2013

I am having the same issue. Our current solution has been to delete the .xcasset folder that belongs to any target we are not building for.

@barksten

This comment has been minimized.

Show comment
Hide comment
@barksten

barksten Jan 9, 2014

I've poking around in the copy resource script and found that the .xcassets part in install_resource() was empty.
I guess it should be handled in that function instead of just copying all files. I'll have a look tonight.

barksten commented Jan 9, 2014

I've poking around in the copy resource script and found that the .xcassets part in install_resource() was empty.
I guess it should be handled in that function instead of just copying all files. I'll have a look tonight.

@coneybeare

This comment has been minimized.

Show comment
Hide comment
@coneybeare

coneybeare Jan 23, 2014

I posted about this problem on my blog, though I did not know it was related to CocoaPods until a commenter pointed it out. He also included a possible solution :) Even though it won't work in my case due to some of the pods having xcassets in them, it may get this bug fix on the right track.

http://matt.coneybeare.me/using-xcode-asset-catalogs-with-multiple-targets/#comment-1213336157

coneybeare commented Jan 23, 2014

I posted about this problem on my blog, though I did not know it was related to CocoaPods until a commenter pointed it out. He also included a possible solution :) Even though it won't work in my case due to some of the pods having xcassets in them, it may get this bug fix on the right track.

http://matt.coneybeare.me/using-xcode-asset-catalogs-with-multiple-targets/#comment-1213336157

@knightsc

This comment has been minimized.

Show comment
Hide comment
@knightsc

knightsc Feb 12, 2014

I'm also having this issue. None of the pods I use have any extra xcassets in them. How hard would it be to modify the copy_resources_script.rb so that when it checked if there were any xcassets it only checked if there were xcassets within the pod projects. Then at least for people who dont have pods that include extra xcassets it won't mess up their build. Something as simple as changing this line

if [[ -n "${WRAPPER_EXTENSION}" ]] && [ `xcrun --find actool` ] && [ `find . -name '*.xcassets' | wc -l` -ne 0 ]```

to this

if [[ -n "${WRAPPER_EXTENSION}" ]] && [ `xcrun --find actool` ] && [ `find Pods -name '*.xcassets' | wc -l` -ne 0 ]

knightsc commented Feb 12, 2014

I'm also having this issue. None of the pods I use have any extra xcassets in them. How hard would it be to modify the copy_resources_script.rb so that when it checked if there were any xcassets it only checked if there were xcassets within the pod projects. Then at least for people who dont have pods that include extra xcassets it won't mess up their build. Something as simple as changing this line

if [[ -n "${WRAPPER_EXTENSION}" ]] && [ `xcrun --find actool` ] && [ `find . -name '*.xcassets' | wc -l` -ne 0 ]```

to this

if [[ -n "${WRAPPER_EXTENSION}" ]] && [ `xcrun --find actool` ] && [ `find Pods -name '*.xcassets' | wc -l` -ne 0 ]
@morten-holm

This comment has been minimized.

Show comment
Hide comment
@morten-holm

morten-holm Feb 19, 2014

I'm having the same problem on my current project. The project is being built continuously by a jenkins server that cleans the directory and runs pod install on every build, so a more durable solution than editing the Pods-resources.sh script would be preferred.

morten-holm commented Feb 19, 2014

I'm having the same problem on my current project. The project is being built continuously by a jenkins server that cleans the directory and runs pod install on every build, so a more durable solution than editing the Pods-resources.sh script would be preferred.

@rfsbraz

This comment has been minimized.

Show comment
Hide comment
@rfsbraz

rfsbraz Feb 22, 2014

For those having this issue, and having do delete the same lines everytime you pod install, I created a build phase run script that does it automatically, by using sed.

The lines that the script removes are the ones shown in here.

Go to your build phases, Editor>Add Build Phase>Add Run Script Build Phase.
Paste in the following code:

# Backup the original file
if [ ! -f Pods/Pods-resources.sh.bak ];
then
    cp Pods/Pods-resources.sh Pods/Pods-resources.sh.bak
fi

sed '/if \[\[ -n "\${WRAPPER_EXTENSION}" ]] \&\& \[ `xcrun --find actool` \] \&\& \[ `find \. -name '\''\*\.xcassets'\'' \| wc -l` -ne 0 \]/,/fi\n/d' Pods/Pods-resources.sh > Pods/Pods-resources.sh.temp
sed '/*.xcassets)/,/;;/d' Pods/Pods-resources.sh.temp > Pods/Pods-resources.sh
rm Pods/Pods-resources.sh.temp

Important: Move your script above the existing Copy Pods Resources.

screenshot 2014-02-22 15 38 07

This can probably be made shorter by piping the results, but meh.

rfsbraz commented Feb 22, 2014

For those having this issue, and having do delete the same lines everytime you pod install, I created a build phase run script that does it automatically, by using sed.

The lines that the script removes are the ones shown in here.

Go to your build phases, Editor>Add Build Phase>Add Run Script Build Phase.
Paste in the following code:

# Backup the original file
if [ ! -f Pods/Pods-resources.sh.bak ];
then
    cp Pods/Pods-resources.sh Pods/Pods-resources.sh.bak
fi

sed '/if \[\[ -n "\${WRAPPER_EXTENSION}" ]] \&\& \[ `xcrun --find actool` \] \&\& \[ `find \. -name '\''\*\.xcassets'\'' \| wc -l` -ne 0 \]/,/fi\n/d' Pods/Pods-resources.sh > Pods/Pods-resources.sh.temp
sed '/*.xcassets)/,/;;/d' Pods/Pods-resources.sh.temp > Pods/Pods-resources.sh
rm Pods/Pods-resources.sh.temp

Important: Move your script above the existing Copy Pods Resources.

screenshot 2014-02-22 15 38 07

This can probably be made shorter by piping the results, but meh.

@kylef kylef added the Resources label Mar 14, 2014

@andrewip

This comment has been minimized.

Show comment
Hide comment
@andrewip

andrewip Mar 17, 2014

I just tried out @barksten's workaround. In my particular case, I reordered the "Copy Pods Resources" build phase to occur right before the "Copy Bundle Resources" build phase. The resulting workaround works quite well without having to delete sections of the Pod-resources.sh script file.

andrewip commented Mar 17, 2014

I just tried out @barksten's workaround. In my particular case, I reordered the "Copy Pods Resources" build phase to occur right before the "Copy Bundle Resources" build phase. The resulting workaround works quite well without having to delete sections of the Pod-resources.sh script file.

@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

pawanpoudel added a commit to pawanpoudel/Branded that referenced this issue Apr 15, 2014

Only replace assets in Pods directory during build
Otherwise, we won't be able to generate multiple
builds with desired images.

See this issue in Github for more detail:
CocoaPods/CocoaPods#1546

pawanpoudel added a commit to pawanpoudel/Branded that referenced this issue Apr 15, 2014

Only replace assets in Pods directory during build
Otherwise, we won't be able to generate multiple
builds with desired images.

See this issue in Github for more detail:
CocoaPods/CocoaPods#1546
@jinthagerman

This comment has been minimized.

Show comment
Hide comment
@jinthagerman

jinthagerman May 14, 2014

Contributor

I'm having this issue also.

Another workaround based on @rfsbraz idea. I've basically added @rfsbraz script to my post_install hook. My ruby is pretty basic so I'm just calling the script from ruby. I've also simplified the sed regexes a bit so they are a bit more readable. It might be worth putting into it's own script, but I like having it all contained in the podfile.

I like this because it isn't run everytime you build and automatically removes this for all targets.

post_install do |installer|
  installer.project.targets.each do |target|
    %x~ if [ ! -f Pods/#{target.name}-resources.sh.bak ]; then cp Pods/#{target.name}-resources.sh Pods/#{target.name}-resources.sh.bak; fi ~

    %x~ sed '/WRAPPER_EXTENSION/,/fi\\n/d' Pods/#{target.name}-resources.sh > Pods/#{target.name}-resources.sh.temp ~
    %x~ sed '/*.xcassets)/,/;;/d' Pods/#{target.name}-resources.sh.temp > Pods/#{target.name}-resources.sh ~
    %x~ rm Pods/#{target.name}-resources.sh.temp ~
  end
end
Contributor

jinthagerman commented May 14, 2014

I'm having this issue also.

Another workaround based on @rfsbraz idea. I've basically added @rfsbraz script to my post_install hook. My ruby is pretty basic so I'm just calling the script from ruby. I've also simplified the sed regexes a bit so they are a bit more readable. It might be worth putting into it's own script, but I like having it all contained in the podfile.

I like this because it isn't run everytime you build and automatically removes this for all targets.

post_install do |installer|
  installer.project.targets.each do |target|
    %x~ if [ ! -f Pods/#{target.name}-resources.sh.bak ]; then cp Pods/#{target.name}-resources.sh Pods/#{target.name}-resources.sh.bak; fi ~

    %x~ sed '/WRAPPER_EXTENSION/,/fi\\n/d' Pods/#{target.name}-resources.sh > Pods/#{target.name}-resources.sh.temp ~
    %x~ sed '/*.xcassets)/,/;;/d' Pods/#{target.name}-resources.sh.temp > Pods/#{target.name}-resources.sh ~
    %x~ rm Pods/#{target.name}-resources.sh.temp ~
  end
end

tomdalling added a commit to tomdalling/CocoaPods that referenced this issue May 31, 2014

Only include *.xcassets from Pods
Fixes CocoaPods#1546

If you had multiple xcassets anywhere underneath your root project directory, but were only picking one of them for each build, the `Pods-resources.sh` script would include ALL of them in the build. This could cause resources from the correct xcassets to be overwritten by all the others.

Now, `Pods-resources.sh` will only include the xcassets found in `Pods`. All other xcassets can be included in the build by adding them to the Xcode project, as per usual.
@tomdalling

This comment has been minimized.

Show comment
Hide comment
@tomdalling

tomdalling May 31, 2014

Is pull request #2212 sufficient to fix this? It fixes the issue for my own project, but I could be overlooking something.

tomdalling commented May 31, 2014

Is pull request #2212 sufficient to fix this? It fixes the issue for my own project, but I could be overlooking something.

@fabiotk

This comment has been minimized.

Show comment
Hide comment
@fabiotk

fabiotk Jun 17, 2014

I have the same issue

fabiotk commented Jun 17, 2014

I have the same issue

@lstroud

This comment has been minimized.

Show comment
Hide comment
@lstroud

lstroud Jul 13, 2014

I have the same issue. The project has xcassets. None of the pods have xcassets. I don't get this error building the main target. Instead, I get it building the test target.

@rfsbraz 's solution works as a temporary workaround

lstroud commented Jul 13, 2014

I have the same issue. The project has xcassets. None of the pods have xcassets. I don't get this error building the main target. Instead, I get it building the test target.

@rfsbraz 's solution works as a temporary workaround

@zygoat

This comment has been minimized.

Show comment
Hide comment
@zygoat

zygoat Jul 17, 2014

Contributor

I was just bitten by this last night too while re-organizing our project to make better use of xcassets. After several hours of confusion and frustration mis-directed at Xcode, googling finally led me to @coneybeare's blog post from which I found this issue. I've successfully implemented @rfsbraz's workaround in the interim, and look forward to this being properly fixed in CocoaPods.

Thank you all for documenting and diagnosing the problem!

Contributor

zygoat commented Jul 17, 2014

I was just bitten by this last night too while re-organizing our project to make better use of xcassets. After several hours of confusion and frustration mis-directed at Xcode, googling finally led me to @coneybeare's blog post from which I found this issue. I've successfully implemented @rfsbraz's workaround in the interim, and look forward to this being properly fixed in CocoaPods.

Thank you all for documenting and diagnosing the problem!

@kishinmanglani

This comment has been minimized.

Show comment
Hide comment
@kishinmanglani

kishinmanglani Apr 6, 2015

Does 0.36.1 or 0.36.2 change any of this? Is the above still the best solution?

kishinmanglani commented Apr 6, 2015

Does 0.36.1 or 0.36.2 change any of this? Is the above still the best solution?

@irace

This comment has been minimized.

Show comment
Hide comment
@irace

irace Apr 7, 2015

Still seeing this problem with 0.36.3.

irace commented Apr 7, 2015

Still seeing this problem with 0.36.3.

@irace

This comment has been minimized.

Show comment
Hide comment
@irace

irace Apr 7, 2015

@AliSoftware Your branch seemed to fix our issues. Do you expect it to go into, say, a 0.36.4 release?

irace commented Apr 7, 2015

@AliSoftware Your branch seemed to fix our issues. Do you expect it to go into, say, a 0.36.4 release?

@irace

This comment has been minimized.

Show comment
Hide comment
@irace

irace Apr 7, 2015

@AliSoftware I may have spoke too soon, actually. It looks like running pod install using your branch results in a new duplicate reference to my .xcdatamodeld file being added to the Xcode project each time.

irace commented Apr 7, 2015

@AliSoftware I may have spoke too soon, actually. It looks like running pod install using your branch results in a new duplicate reference to my .xcdatamodeld file being added to the Xcode project each time.

@AliSoftware

This comment has been minimized.

Show comment
Hide comment
@AliSoftware

AliSoftware Apr 7, 2015

Contributor

@irace You mean that the first time you run pod install you got your pod's .xcdatamodel file added and present only once, but if you re-run pod install you got it added again?

Contributor

AliSoftware commented Apr 7, 2015

@irace You mean that the first time you run pod install you got your pod's .xcdatamodel file added and present only once, but if you re-run pod install you got it added again?

@irace

This comment has been minimized.

Show comment
Hide comment
@irace

irace Apr 7, 2015

@AliSoftware That seems to be the case, yes.

irace commented Apr 7, 2015

@AliSoftware That seems to be the case, yes.

@frandelarosa

This comment has been minimized.

Show comment
Hide comment
@frandelarosa

frandelarosa Apr 10, 2015

Any news on this? Can't run the project properly without to do clean before. I tried to use the fix proposed by @T-Pham but I'm not sure if I set it correctly. Maybe something is wrong with my project path.

frandelarosa commented Apr 10, 2015

Any news on this? Can't run the project properly without to do clean before. I tried to use the fix proposed by @T-Pham but I'm not sure if I set it correctly. Maybe something is wrong with my project path.

chrisfsampaio added a commit to chrisfsampaio/CocoaPods that referenced this issue Apr 13, 2015

Fixing frameworks with Today Widgets
Adding Modules to the excluded list folders in order make Today Widgets sign in properly, might fix CocoaPods#1546

@kylef kylef closed this in b13733d Apr 15, 2015

@lukemelia

This comment has been minimized.

Show comment
Hide comment
@lukemelia

lukemelia Apr 15, 2015

Considering the commit message that closed this, should this issue be reopened until a fix is confirmed?

lukemelia commented Apr 15, 2015

Considering the commit message that closed this, should this issue be reopened until a fix is confirmed?

@slhodson969

This comment has been minimized.

Show comment
Hide comment
@slhodson969

slhodson969 Apr 16, 2015

None of the scripts seem to be working for me. I am meant to be uploading an app to Apple today but the iPad target ignores its assets folder so has no app icon.

Is there an updated Cocoapods version that has this fix in?

slhodson969 commented Apr 16, 2015

None of the scripts seem to be working for me. I am meant to be uploading an app to Apple today but the iPad target ignores its assets folder so has no app icon.

Is there an updated Cocoapods version that has this fix in?

@sashagood

This comment has been minimized.

Show comment
Hide comment
@sashagood

sashagood Apr 16, 2015

Is someone have any news? Can't use pods because of this bug.

sashagood commented Apr 16, 2015

Is someone have any news? Can't use pods because of this bug.

@wiistriker

This comment has been minimized.

Show comment
Hide comment
@wiistriker

wiistriker Apr 16, 2015

Same error for me

wiistriker commented Apr 16, 2015

Same error for me

@orta

This comment has been minimized.

Show comment
Hide comment
@orta
Member

orta commented Apr 16, 2015

You're welcome to test and see if master fixes your problem, https://github.com/CocoaPods/guides.cocoapods.org/blob/gemfile/source/using/a-gemfile.html.md

@AliSoftware

This comment has been minimized.

Show comment
Hide comment
@AliSoftware

AliSoftware Apr 16, 2015

Contributor

A bit of update: We will provide a fix in an upcoming release, that won't properly fix this #1546 (white-label apps, a.k.a multiple xcassets in various targets in the user's project), but that will fix cases for pods with xcassets.

The matter at hand with the current 1546 issue is way more complex that we first imagined, and will require a more complex approach. I already tried a bunch of ideas in the past month, sadly those refactoring and trials failed to cover every use case, so we still need to decide which way we'll be going from there to fix 1546 with a better, proper solution.

Contributor

AliSoftware commented Apr 16, 2015

A bit of update: We will provide a fix in an upcoming release, that won't properly fix this #1546 (white-label apps, a.k.a multiple xcassets in various targets in the user's project), but that will fix cases for pods with xcassets.

The matter at hand with the current 1546 issue is way more complex that we first imagined, and will require a more complex approach. I already tried a bunch of ideas in the past month, sadly those refactoring and trials failed to cover every use case, so we still need to decide which way we'll be going from there to fix 1546 with a better, proper solution.

@kishinmanglani

This comment has been minimized.

Show comment
Hide comment
@kishinmanglani

kishinmanglani Apr 16, 2015

Is swapping the build phase order still a reliable fix? Does the order get reset when pod install is run?

kishinmanglani commented Apr 16, 2015

Is swapping the build phase order still a reliable fix? Does the order get reset when pod install is run?

@kylef

This comment has been minimized.

Show comment
Hide comment
@kylef

kylef Apr 16, 2015

Contributor

This wasn't meant to be closed.

Contributor

kylef commented Apr 16, 2015

This wasn't meant to be closed.

@kylef kylef reopened this Apr 16, 2015

@x2on

This comment has been minimized.

Show comment
Hide comment
@x2on

x2on Apr 17, 2015

So it looks like 0.36.4 fixed the issue for me for using Watch Extension and CocoaPods.

x2on commented Apr 17, 2015

So it looks like 0.36.4 fixed the issue for me for using Watch Extension and CocoaPods.

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

Fixing frameworks with Today Widgets
Adding Modules to the excluded list folders in order make Today Widgets sign in properly, might fix CocoaPods#1546
@niveus

This comment has been minimized.

Show comment
Hide comment
@niveus

niveus May 21, 2015

Still having this issue in 0.37.1. Fixed it reordering the build phases and adding @T-Pham 's script phase: find ${PROJECT_DIR} -name "*.xcassets" -exec touch {} \+; before the Copy Bundle Resources phase

niveus commented May 21, 2015

Still having this issue in 0.37.1. Fixed it reordering the build phases and adding @T-Pham 's script phase: find ${PROJECT_DIR} -name "*.xcassets" -exec touch {} \+; before the Copy Bundle Resources phase

@AlbertTong

This comment has been minimized.

Show comment
Hide comment
@AlbertTong

AlbertTong Jun 9, 2015

Used to be an issue previously but hasn't been an issue since upgrading to 0.37.1 (was on 0.34 previously with a manual workaround to the Pods-resources.sh file)

AlbertTong commented Jun 9, 2015

Used to be an issue previously but hasn't been an issue since upgrading to 0.37.1 (was on 0.34 previously with a manual workaround to the Pods-resources.sh file)

@AliSoftware

This comment has been minimized.

Show comment
Hide comment
@AliSoftware

AliSoftware Sep 9, 2015

Contributor

My work was abandoned because it couldn't work at all with
configuration-dependent pods so didn't fit all the cases
Le mer. 9 sept. 2015 à 22:40, Rafael Nobre notifications@github.com a
écrit :

@AliSoftware https://github.com/AliSoftware any news on this? Your
approach looked fine as actool should only try to compile user assets with
the right target ownership. I have a white-label project idea stalled
because of this one, I may contribute a sample project of my use case if
you need it.


Reply to this email directly or view it on GitHub
#1546 (comment)
.

Contributor

AliSoftware commented Sep 9, 2015

My work was abandoned because it couldn't work at all with
configuration-dependent pods so didn't fit all the cases
Le mer. 9 sept. 2015 à 22:40, Rafael Nobre notifications@github.com a
écrit :

@AliSoftware https://github.com/AliSoftware any news on this? Your
approach looked fine as actool should only try to compile user assets with
the right target ownership. I have a white-label project idea stalled
because of this one, I may contribute a sample project of my use case if
you need it.


Reply to this email directly or view it on GitHub
#1546 (comment)
.

@nobre84

This comment has been minimized.

Show comment
Hide comment
@nobre84

nobre84 Sep 9, 2015

I see. I realized that your efforts tried to fix assets coming from Pods, while the issue with multiple assets in user targets being broken is just a side effect of the current pods-resources script, am I right on these conclusions? What would be the simplest work-around to allow this white label use case to work?

nobre84 commented Sep 9, 2015

I see. I realized that your efforts tried to fix assets coming from Pods, while the issue with multiple assets in user targets being broken is just a side effect of the current pods-resources script, am I right on these conclusions? What would be the simplest work-around to allow this white label use case to work?

@a13xb

This comment has been minimized.

Show comment
Hide comment
@a13xb

a13xb Jan 11, 2016

I have run into the same problem. In our project we need to support all of these:

  1. shared user asset catalogs
  2. per-target user asset catalos
  3. pods with asset catalogs

I ended up fudging the resource script from Podfile post-install hook.

The downside is that you have to re-run pod install if application's asset catalogs are added or removed. But it almost never happens in our case (YMMV). Pods asset catalogs change more often, so I've put it in the post-install hook, as opposed to a standalone script. It's dirty but it works.

a13xb commented Jan 11, 2016

I have run into the same problem. In our project we need to support all of these:

  1. shared user asset catalogs
  2. per-target user asset catalos
  3. pods with asset catalogs

I ended up fudging the resource script from Podfile post-install hook.

The downside is that you have to re-run pod install if application's asset catalogs are added or removed. But it almost never happens in our case (YMMV). Pods asset catalogs change more often, so I've put it in the post-install hook, as opposed to a standalone script. It's dirty but it works.

@neonichu

This comment has been minimized.

Show comment
Hide comment
@neonichu

neonichu May 2, 2016

Member

This issue has been inactive for a long time and will be closed because we want to move forward with a clean slate after our 1.0 release. If you believe this is still relevant, please retest with the 1.0 release candidate and comment with a reproducible project in order for this to become actionable again. Thanks!

Member

neonichu commented May 2, 2016

This issue has been inactive for a long time and will be closed because we want to move forward with a clean slate after our 1.0 release. If you believe this is still relevant, please retest with the 1.0 release candidate and comment with a reproducible project in order for this to become actionable again. Thanks!

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