8000 Xcode10 (new build system) - if incremental build, Embed script doesn't run · Issue #8073 · CocoaPods/CocoaPods · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Xcode10 (new build system) - if incremental build, Embed script doesn't run #8073

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

Closed
1 task done
mkubista opened this issue Sep 3, 2018 · 57 comments · Fixed by #8105
Closed
1 task done

Xcode10 (new build system) - if incremental build, Embed script doesn't run #8073

mkubista opened this issue Sep 3, 2018 · 57 comments · Fixed by #8105
Labels
r:new build system Issues related to Xcode's new build system introduced in Xcode 9 s2:confirmed Issues that have been confirmed by a CocoaPods contributor s7:workaround available A workaround for the issue is available
Milestone

Comments

@mkubista
Copy link
mkubista commented Sep 3, 2018

READ THIS FIRST (08/23/2019 update by @dnkoutso)

UPDATE 06/22/2020

Xcode 12 also claims to fix the issue for xcfilelists! (https://developer.apple.com/documentation/xcode-release-notes/xcode-12-beta-release-notes)

For CocoaPods > 1.8.0.beta.1 a fix was merged in #9125 by using USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES instead of ALLOW_RECURSIVE_SCRIPT_INPUTS that Xcode 11 Beta notes have mistakenly said.

However, #9125 still does NOT work if your project uses xcfilelists which CocoaPods utilizes automatically and as long as your project is Xcode 9.3 compatible.

An additional radar has been filed to Apple for xcfilelist to work with USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES.


Report

What did you do?

ℹ I made changes in some code files in local development pod

What did you expect to happen?

ℹ After build and run in xCode, the changes are incorporated into the resulting package.

What happened instead?

ℹ The old binary is in package. The [CP] Embed Pods Frameworks script doesnt run. Its because of build optimalisation in new xCode - when it detects no change in input or output files specified for script, the script is not started.
When we did enter the binary file from the content of the .framework folder into the input files list, everything is OK. Clean build is also OK.
So the solution would be to have no input and out files at all, or during pod install add also content files of frameworks into the input files list.

Strange thing - in the build log in Report navigator, the output of the [CP] Embed Pods Frameworks appeared even when it didn't actually run (I modified the script to echo current time, so I can see the same time stamps)

CocoaPods Environment

   CocoaPods : 1.6.0.beta.1
        Ruby : ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16]
    RubyGems : 2.6.11
        Host : Mac OS X 10.14 (18A371a)
       Xcode : 10.0 (10L232m)
         Git : git version 2.17.1 (Apple Git-112)
Ruby lib dir : /usr/local/Cellar/ruby/2.4.1_1/lib
Repositories : artsy - https://github.com/Artsy/Specs.git @ 8c00e26ca1bd8ba163587f0eb592e9cd5a241d0e
               master - https://github.com/CocoaPods/Specs.git @ 058895fdadffd84d53c3ddc27a31591ea2f89ce7
               SSCPWrapper - https://tfs.kswr.cz/tfs/DefaultCollection/Jablotron/_git/MyCompany-iOS @ 518f383f1524b77aad7ddaa1d50eb72e4b824594

Project that demonstrates the issue

ℹ Unfortunately, project cannot be shown in public.

@Legoless
Copy link
Legoless commented Sep 3, 2018

I have the same issue. This causes me having to rebuild the entire project, which takes about 15 minutes. But I only changed a single line in code in one of the development pods.

@mkubista
Copy link
Author
mkubista commented Sep 3, 2018

I have a possible temporary solution
I added this Run script phase before Embed Pods Framework
touch "${PODS_ROOT}/*SCRIPT_DIRECTORY*frameworks.sh"
The real dirctory can be found in XCODE log of the build.
It forces xcode to run the script everytime. Because inside is used rsync command, the time to do this every-time isn't as much long

@dnkoutso
Copy link
Contributor
dnkoutso commented Sep 3, 2018

Even in the current build system the input/output files are used to speed up builds. If nothing has changed then there is no need to run these scripts.

Please include a sample app demonstrating this issue as I cannot reproduce locally.

@dnkoutso dnkoutso added s6:need sample Needs a sample project that reproduces the issue s1:awaiting input Waiting for input from the original author labels Sep 3, 2018
@mkubista
Copy link
Author
mkubista commented Sep 3, 2018

Here is the sample project https://github.com/mkubista/CocoapodsTest
The problem can be simulated by this steps:

  1. Build and run the project - the viewcontroller with "Test 2" label should appear.
  2. Change the code in cocoapods module in CocoapodsTest.Submodule/CocoapodsTestSubmodule/Utils.swift for example to return "Test 1" instead.
  3. Build and run again - one would think the "Test 1" will appear but "Test 2" is here. Clean build will solve this.

Project is in git with all necessary files.
I hope the problem is not on my computer only (if so I have no clue what could cause this)

@stale stale bot removed the s1:awaiting input Waiting for input from the original author label Sep 3, 2018
@djbe
Copy link
djbe commented Sep 4, 2018

I have the same issue in a large project with around 6 development pods.

Whenever we modify anything in a development pod, we are forced to perform a full clean & build before the changes are propagated on device (or in simulator).

@dnkoutso dnkoutso removed the s6:need sample Needs a sample project that reproduces the issue label Sep 4, 2018
@dnkoutso
Copy link
Contributor
dnkoutso commented Sep 4, 2018

Thanks for sample will take a look when time permits.

@dnkoutso
Copy link
Contributor
dnkoutso commented Sep 4, 2018

Confirmed.

@dnkoutso dnkoutso added t2:defect These are known bugs. The issue should also contain steps to reproduce. PRs welcome! s2:confirmed Issues that have been confirmed by a CocoaPods contributor d2:moderate A moderately-difficult ticket that may require a bit of knowledge about the codebase r:new build system Issues related to Xcode's new build system introduced in Xcode 9 labels Sep 4, 2018
@dnkoutso dnkoutso added this to the 1.6.0 milestone Sep 4, 2018
@dnkoutso
Copy link
Contributor
dnkoutso commented Sep 4, 2018

Quick debugging shows its a new build system issue only and despite the file timestamp changing Xcode does not treat the resulting framework as "dirty" and therefore skips the script phase...

Will try to see if I can work around it but unfortunately this might need to be a radar instead.

@dnkoutso
Copy link
Contributor
dnkoutso commented Sep 4, 2018

This is an unfortunate regression in Xcode 10 new build system. Switching to legacy system makes it work just fine.

I believe Apple is aware of this. Switching the input/output paths to point to the actual executable inside the framework makes the problem go away but we may not want to do that. This means that the script phases will re-run correctly as long as the sources of the framework change but it won't catch resource changes or other things inside the .framework folder.

For now it seems that Xcode 10 build system will always require a clean build to ensure latest changes are present which sucks.

We could maybe add an option to not use input/output paths which would "fix" this but it is ultimately a workaround.

@mkubista
Copy link
Author
mkubista commented Sep 5, 2018

I will try to report it in Apple Bug reporter. Will see, what they will say...

@maxkattner
Copy link

I created a radar (41126633) for that in June. They are aware, got a sample project and are working on fixing it. Unfortunately, I do not have any more information.
Feel free to created dupes as it helps them in prioritising!

@dnkoutso
Copy link
Contributor

Thank you!!

@dnkoutso dnkoutso removed the t2:defect These are known bugs. The issue should also contain steps to reproduce. PRs welcome! label Sep 13, 2018
@dnkoutso dnkoutso added the s7:workaround available A workaround for the issue is available label Sep 18, 2018
jverkoey pushed a commit to jverkoey/material-components-ios that referenced this issue Sep 18, 2018
The new Xcode 10 build system does not play well with CocoaPods, resulting in iterative builds not picking up changes in source files. This results in a remarkably frustrating debugging experience because breakpoints will often not be associated with the lines you expect them to be, and functionality that you're testing won't actually be testable until you perform a clean build.

See CocoaPods/CocoaPods#8073 for additional details.
@dmcgloin
Copy link

FYI: Tested on Xcode 10.1 beta (10O23u) and issue still occurs.

@dnkoutso
Copy link
Contributor

I think the best thing for us to do is to provide an option not to use input/output paths. This will cause the script phase to run always but at least folks wont have to do clean builds.

@forwyt
Copy link
forwyt commented Jul 11, 2019

Just click File->Project(WorkingSpack)Settings ->Build system (Legacy Build System) will make the problem ok !
it's work for me .

@igor-makarov
Copy link
Contributor

How about Beta 4?

@dnkoutso
Copy link
Contributor

Doesn't work on Xcode 11 Beta 4 either.

@maxkattner
Copy link

The official workaround is to set a user-defined build setting USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES to YES. This should already work with Xcode 11 Beta 1 and later versions. Sadly, the flag they announced in a previous changelog entry was wrong but this one now works just fine. Not sure if it there is the will to make this setting default or include it in the predefined build settings. Only time will tell. 🤷‍♂😄

@igor-makarov
Copy link
Contributor

I tested this right now and it works.

I only have expletives.

@dnkoutso
Copy link
Contributor

@maxkattner omg. I wish we would have known this earlier.........................! Was this a response from Apple to your radar?

@maxkattner
Copy link

One of their developers pointed me to the changelog and then noticed the mistake in its name provided in the document. I just checked and it is still wrongly named in the changelog.

@dnkoutso
Copy link
Contributor

@maxkattner tried it, it works with normal input/output paths but doesn't work with xcfilelists.........

@maxkattner
Copy link

Did you already file a radar yourself? If not please do so and give them this additional info there. Thanks!

@dnkoutso
Copy link
Contributor

I had one filed yes and updated it with that info. I think i might file a new one though as my existing one was marked as a duplicate.

@dnkoutso
Copy link
Contributor

1.8.0.beta.2 was released that fixes this issue by using USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES but only if xcfilelists are not used.

@nickgzzjr
Copy link

@dnkoutso Is there a way to disable xcfilelists so that USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES works?

@nservidio
Copy link

Hey, sorry, I'm late to this discussion,

  • I'm using Xcode Version 10.3 (10G8)
  • pod Version 1.8.4
  • find . -name '*.xcfilelist' yields no results in my project folder.

Adding this to my Podfile:

install! 'cocoapods', :disable_input_output_paths => true

Or setting my workspace build system to legacy does not allow me to pick up incremental changes in a "development" pod (pod 'foo', :path => '~/Developer/foo'). Cleaning doesn't seem to help either. I'm getting confused about all the different workarounds presented. Am I missing something?

Please let me know! Thanks!

@joaquin102
Copy link
joaquin102 commented Jan 26, 2020

This is going to solve all your issues. 100% confirmed!! https://stackoverflow.com/questions/50552752/how-to-rebuild-development-pod-changes

@acecilia
Copy link
acecilia commented May 13, 2020

@nickgzzjr To fix the issue you can disable xcfilelists by setting objectVersion to 48. You can do that with the following pre_install step to your Podfile (cocoapods only uses xcfilelists for objectVersion >= 50):

pre_install do |installer|
  # Workaround for https://github.com/CocoaPods/CocoaPods/issues/8073
  # For more context see https://github.com/CocoaPods/CocoaPods/issues/8073#issuecomment-628092129
  installer.analysis_result.targets.each do |target|
    project_path = target.user_project.path + "project.pbxproj"
    text = File.read(project_path)
    new_contents = text.gsub(/objectVersion = .*/, "objectVersion = 48;")
    File.open(project_path, "w") {|file| file.puts new_contents }
  end
end 

@dnkoutso
Copy link
Contributor
dnkoutso commented Jun 22, 2020

Xcode 12 beta 1 claims to be fixing the issue with xcfilelists as well:

When using USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES with XCFileLists, the items within are now properly treated as recursive inputs. (54635196) (FB7109342)

Release notes https://developer.apple.com/documentation/xcode-release-notes/xcode-12-beta-release-notes

@dnkoutso
Copy link
Contributor

CocoaPods has already been updated to use USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES so we expect things to just start working.

@dnkoutso
Copy link
Contributor

Confirmed Xcode 12 Beta 1 fixes this issue with the project given in comment #8073 (comment)

Keeping this closed.

@teameh
Copy link
teameh commented Jun 22, 2020

Haha you're fast 👍 😄

@adamdahan
Copy link

Just a heads up non of this was fixed in Xcode 13. Bug still exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
r:new build system Issues related to Xcode's new build system introduced in Xcode 9 s2:confirmed Issues that have been confirmed by a CocoaPods contributor s7:workaround available A workaround for the issue is available
Projects
None yet
Development

Successfully merging a pull request may close this issue.

0