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

Pod install includes all xcassets from all targets #6159

Closed
mfclarke opened this issue Nov 11, 2016 · 27 comments

Comments

Projects
None yet
9 participants
@mfclarke
Copy link

commented Nov 11, 2016

Before you start, are you using the CocoaPods beta release?
a lot has changed with Xcode 8 that is not backwards compatible.

Xcode 8 Status: Only works with CocoaPods 1.1.0
Swift 3: You need to add a .swift-version file, see the CHANGELOG
China: Use https://gems.ruby-china.org/ instead of https://gems.ruby-china.org/ for the RC see #5910

Report

What did you do?

Run pod install using CocoaPods 1.1.1. Then build a multi target project.

What did you expect to happen?

The target being built would contain only the xcassets that are associated with the target.

What happened instead?

xcassets were bundled in from all targets in the project

CocoaPods Environment

Stack

   CocoaPods : 1.1.1
        Ruby : ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin15]
    RubyGems : 2.6.1
        Host : Mac OS X 10.11.6 (15G31)
       Xcode : 7.3 (7D175)
         Git : git version 2.6.4 (Apple Git-63)
Ruby lib dir : /Users/clarkema/.rbenv/versions/2.2.3/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 18f0f12182e1056fd893af80c31fecc4c711fd34
               master-1 - git@github.com:CocoaPods/Specs.git @ 27c05d97d019671c4bcde9f3f2f4a4731d8c0036
               redacted - internal company repos

Installation Source

Executable Path: /Users/clarkema/.rbenv/versions/2.2.3/bin/pod

Plugins

cocoapods-deintegrate  : 1.0.1
cocoapods-dependencies : 0.5.2
cocoapods-plugins      : 1.0.0
cocoapods-search       : 1.0.0
cocoapods-stats        : 1.0.0
cocoapods-trunk        : 1.1.1
cocoapods-try          : 1.1.0

Podfile

source 'git@github.com:CocoaPods/Specs.git'
source 'redacted - internal company repo'

platform :ios, "8.0"
inhibit_all_warnings!

def common_pods
  pod 'Reachability', '~> 3.2'
  pod 'SDWebImage', '~> 3.7'
  pod 'FLAnimatedImage', '~> 1.0'
end

target "MyTarget" do
  common_pods

  target 'UnitTests' do
    inherit! :search_paths
    pod 'Nocilla', :configurations => ['Debug']
  end
end

target "MyTarget2" do
  common_pods
end
target "MyTarget3" do
  common_pods
end
target "MyTarget4" do
  common_pods
end
target "MyTarget5" do
  common_pods
end


post_install do |installer|
    puts("Update debug pod settings to speed up build time")
    Dir.glob(File.join("Pods", "**", "Pods*{debug,Private}.xcconfig")).each do |file|
        File.open(file, 'a') { |f| f.puts "\nDEBUG_INFORMATION_FORMAT = dwarf" }
    end
end
@mfclarke

This comment has been minimized.

Copy link
Author

commented Nov 12, 2016

I believe the problem is this section of the generated resource copy script:

https://github.com/CocoaPods/CocoaPods/blob/master/lib/cocoapods/generator/copy_resources_script.rb#L190

Maybe we can get a list of xcassets that are actually part of the target using xcodeproj?

@drico

This comment has been minimized.

Copy link

commented Nov 28, 2016

I have the same issue.

@mfclarke

This comment has been minimized.

Copy link
Author

commented Dec 5, 2016

I'd just like to add that we started experiencing a crash during the copy pods resources phase. The output from our CI:

[02:46:50]: ▸ Running script 'Copy Pods Resources'
[02:47:04]: ▸ Testing failed:
[02:47:04]: ▸ TDRenditionsDistiller._distill:  Dispatch queue: NSManagedObjectContext 0x7fea0db08dc0
[02:47:04]: ▸ ** TEST FAILED **
[02:47:04]: ▸ The following build commands failed:
[02:47:04]: ▸ PhaseScriptExecution Copy\ Pods\ Resources /Users/distiller/Library/Developer/Xcode/DerivedData/<Redacted>-cgxrnstnbwmdknfkvwpxgpdcqecz/Build/Intermediates/<Redacted>.build/Debug-iphonesimulator/<Redacted>.build/Script-3BF172996E8D8C6785672ED3.sh
[02:47:04]: ▸ (1 failure)

The solution was to comment these lines out from the generated resources.sh scripts:

# Find all other xcassets (this unfortunately includes those of path pods and other targets).
OTHER_XCASSETS=$(find "$PWD" -iname "*.xcassets" -type d)
  while read line; do
    if [[ $line != "${PODS_ROOT}*" ]]; then
      XCASSET_FILES+=("$line")
    fi
  done <<<"$OTHER_XCASSETS"

Then just ensure that the Copy Pods Resources phase happens before the normal Copy Resources phase. This resolved both this issue and the crash. But of course this is a hacky workaround... :)

cc @drico

@almsta

This comment has been minimized.

Copy link

commented Jan 5, 2017

As a workaround I rename all archives I don't want to "merge" before "[CP] Copy Pods Resources" an rename them back afterwards.

@benasher44

This comment has been minimized.

Copy link
Member

commented Jan 6, 2017

@mfclarke what do you mean by "associated with the target"?

@mfclarke

This comment has been minimized.

Copy link
Author

commented Jan 7, 2017

@benasher44 I mean members of the target. For example:

Target Members
Target1 Common.xcassets, Target1.xcassets
Target2 Common.xcassets, Target2.xcassets
Target3 Common.xcassets, Target3.xcassets

I would expect that Target2 would only have assets from Common.xcassets and Target2.xcassets in the .app bundle. But, it also has the contents of the other xcasset bundles due to the way the cocoapods resources.sh script works.

This is especially troublesome when the names of assets in the individual target xcasset bundles are the same. Since they're all copied into the .app bundle they just overwrite the files in there already and you end up with for example Target3's images in Target1's .app bundle.

@benasher44

This comment has been minimized.

Copy link
Member

commented Jan 7, 2017

Hm okay, so you're saying that these targets have .xcassets that are only added in the main project (i.e. outside of your Podfile/pods), and then the resource copy script (from CocoaPods) is kind of re-bundling all of them together, when it's only meant to be doing it for pods?

@mfclarke

This comment has been minimized.

Copy link
Author

commented Jan 7, 2017

Exactly.

The resources.sh specifically searches for all .xcasset bundles outside of the Pods folder and bundles them in. There's probably a good reason for this, but it doesn't play nice if you have multiple targets with different xcasset bundles.

@benasher44

This comment has been minimized.

Copy link
Member

commented Jan 7, 2017

Hm interesting. Thanks for bring this to our attention! This definitely seems like a bug, and we'll try to look into it soon. Of course, we always appreciate PRs, so if you have time/energy to look into this even if it just results in a more detailed analysis of the root cause, we'd appreciate it!

@vhosune

This comment has been minimized.

Copy link

commented Apr 24, 2017

same probleme here when using carthage and cocoapods,it will add assets from the Carthage/Checkouts
I had the problem with facebook/facebook-ios-sdk built using carthage and having assets from FBSDKIntegrationTests included in my app.

@Tibbs

This comment has been minimized.

Copy link

commented May 13, 2017

Is there any update on this? It increased the build time and my app size significantly. I had to move assets files out of asset catalogs to play nicely.
I think it is very serious bug, if you have large asset catalogs it slows down the build time significantly and it can create issues with assets with the same name in different asset catalog for different targets.

@benasher44

This comment has been minimized.

Copy link
Member

commented May 17, 2017

No updates! I'm not sure that anyone is working on this at the moment. It's very likely that this has been an issue for some time, and we'd certainly appreciate anyone's willingness to attempt a PR to fix!

@almsta

This comment has been minimized.

Copy link

commented May 18, 2017

@dnkoutso

This comment has been minimized.

Copy link
Contributor

commented May 18, 2017

@almsta @Tibbs are we sure this is not "fixed" by cleaning the derived data folder? Perhaps the assets of the first target built still remain in the derived data and end up there?

I am looking into this btw.

@dnkoutso

This comment has been minimized.

Copy link
Contributor

commented May 18, 2017

Also wonder if this is fixed by #6694

@almsta

This comment has been minimized.

Copy link

commented May 19, 2017

@dnkoutso since the assets are compiled every time, cleaning the derived data does not work, imo. Did not try #6694

@dnkoutso

This comment has been minimized.

Copy link
Contributor

commented Mar 24, 2018

@almsta, @mfclarke I know this is a very old issue but would love to resurface it. Does anyone have a sample app to use to repro this?

@Tibbs

This comment has been minimized.

Copy link

commented Mar 24, 2018

I don't think it was fixed, I just stopped using asset catalogs as a whole.

@mfclarke

This comment has been minimized.

Copy link
Author

commented Mar 25, 2018

Hey @dnkoutso, in our case all our xcasset bundles contain assets with the same names (just different image content). So in the end the fix for us was ensuring [CP] Copy Pods Resources happens before the regular Copy Bundle Resources phase, so the correct ones overwrite whatever ones cocoapods has copied in already.

I don't have a sample app handy sorry.

@appmagnetics

This comment has been minimized.

Copy link

commented Mar 29, 2018

Confirm still having this issue. CocoaPods 1.4.0

@appmagnetics

This comment has been minimized.

Copy link

commented Mar 29, 2018

@almsta your link to a workaround does not work, can you explain the idea behind?

@almsta

This comment has been minimized.

Copy link

commented Mar 29, 2018

@appmagnetics the mentioned linked contained the following, added to your Podfile:

post_install do |installer_representation|
    # Pods-<target>-resources.sh to only handle target specific xcassert files.
    # orignal workaround found here: https://github.com/2359media/ios-dev-discussions/issues/7
    installer_representation.aggregate_targets.each do |at|
        files = at.user_targets.map{|t|
            t.resources_build_phase.files_references.select{|f|
                f.last_known_file_type == 'folder.assetcatalog'
            }.map{|f|
                Pathname.new(f.real_path).relative_path_from(f.project.path.dirname)
            }
        }.flatten
        script = at.copy_resources_script_path
        files = files.join('" "')
        `sed -i '' 's@OTHER_XCASSETS=.*@XCASSET_FILES+=(\"#{files}\")@' '#{script}'`
    end
end
@appmagnetics

This comment has been minimized.

Copy link

commented Mar 29, 2018

@almsta thanks a lot. Can you explain a bit what happens in your code snippet? You are running copy resources script with the explicit list of files? But what happens with the original copy files script which is installed by CocoaPods - will they get overwritten?

@appmagnetics

This comment has been minimized.

Copy link

commented Mar 29, 2018

@almsta I've compared the original and "fixed" script and I see how it works now, thanks!

@dnkoutso

This comment has been minimized.

Copy link
Contributor

commented May 25, 2018

Definitely a bug. See more here #7779 (comment)

@gh123man

This comment has been minimized.

Copy link

commented Dec 13, 2018

It appears the link to the previous workaround is dead and the workaround posted above does not work for recent version of CocoaPods due to changes in the script.

I have updated the workaround to support the script changes since my team still deals with this issue:

post_install do |installer_representation|
    installer_representation.aggregate_targets.each do |at|
        files = at.user_targets.map{|t|
            t.resources_build_phase.files_references.select{|f|
                f.last_known_file_type == 'folder.assetcatalog'
            }.map{|f|
                Pathname.new(f.real_path).relative_path_from(f.project.path.dirname)
            }
        }.flatten
        script = at.copy_resources_script_path
        files = files.join('\\\\\n')
        `sed -i '' "s@OTHER_XCASSETS=.*@OTHER_XCASSETS=$\'#{files}\'@" '#{script}'`
    end
end
@dnkoutso

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

Superseded by #8431. This is a 2 year old issue and it is still an issue but #8431 is newer with more info and a sample.

@dnkoutso dnkoutso closed this Jan 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.