8000 make warning for new build system · Issue #9056 · CocoaPods/CocoaPods · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

make warning for new build system #9056

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.

Sign up for GitHub

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

Jump to bottom
Closed
1 task done
Speakus opened this issue Jul 30, 2019 · 21 comments
Closed
1 task done

make warning for new build system #9056

Speakus opened this issue Jul 30, 2019 · 21 comments
Labels
help wanted Help from new or existing contributors would be greatly appreciated! s7:workaround available A workaround for the issue is available
Milestone
1.10.0

Comments

@Speakus
Copy link
Speakus commented Jul 30, 2019

Report

What did you do?

ℹ Please replace these two lines with what you did.
use Xcode 10+ (Xcode 10.3 for example)
pod install

What did you expect to happen?

get warning if I use new build system and do not use solution from here:
#8073 (comment)
So your script could check
variable COMMAND_MODE=legacy should be set or Podfile should contains:
install! 'cocoapods', :disable_input_output_paths => true
At least until Xcode 11 will be released

What happened instead?

No warning - And I get surprises runtime.

CocoaPods Environment

v.1.7.5 (latest now)

Project that demonstrates the issue

not required cause we have confirmed and unfixed issue: #8073 which currently have only workaround
@dnkoutso dnkoutso added the r:new build system Issues related to Xcode's new build system introduced in Xcode 9 label Jul 31, 2019
@dnkoutso
Copy link
Contributor

@Speakus see #9125

@dnkoutso dnkoutso added this to the 1.8.0 milestone Aug 24, 2019
@dnkoutso
Copy link
Contributor

Updating this ticket to reflect current status since CocoaPods 1.8.0.beta.2 is released.

@dnkoutso dnkoutso changed the title make warning for new build system USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES doesn't work with xcfilelists Aug 27, 2019
@dnkoutso dnkoutso added the s7:workaround available A workaround for the issue is available label Aug 27, 2019
@dnkoutso
Copy link
Contributor
dnkoutso commented Aug 27, 2019 •
edited
Loading

Workaround: Switch your .xcodeproj format to go < 9.3 Compatible and CocoaPods will not use xcfilelist and incremental compilation should work if you are using CocoaPods >= 1.8.0 and Xcode 11.

@Speakus
Copy link
Author
Speakus commented Aug 27, 2019 •
edited
Loading

@dnkoutso

Updating this ticket to reflect current status since CocoaPods 1.8.0.beta.2 is released.

I'm sorry but changing title does not reflect what initially requested.

My title was "make wa 8000 rning for new build system".
The title about "USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES" is not the same cause the flag "USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES" affect only Xcode 11 builds while my project was used Xcode 10.3

Also I tried to change:

-			compatibilityVersion = "Xcode 10.0";
+			compatibilityVersion = "Xcode 8.0";

and run pod install but this changed nothing - the two folders are completely the same (except this line). Also Pods.xcodeproj will reset compatibility to Xcode 10 if I tried to change it manually... weird.

@dnkoutso
Copy link
Contributor

fair points, reverting title.

@dnkoutso dnkoutso changed the title USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES doesn't work with xcfilelists make warning for new build system Aug 27, 2019
@dnkoutso
Copy link
Contributor

actually, I am still uncertain if we will ever implement this. CocoaPods intentionally has no knowledge of the Xcode version you are using therefore we will never be able to warn if you are using something less than Xcode 11 etc.

@dnkoutso
Copy link
Contributor

The workaround in the other issue around disabling input output paths is currently the correct work around or at the time of this comment use Xcode 11 Beta 6 with CocoaPods 1.8.0.beta.2 and no xcfilelists.

@Speakus
Copy link
Author
Speakus commented Aug 27, 2019 •
edited
Loading

The workaround in the other issue around disabling input output paths is currently the correct work around or at the time of this comment use Xcode 11 Beta 6 with CocoaPods 1.8.0.beta.2 and no xcfilelists.

Unfortunately I did not understand. You told Xcode version does not matter for cocoapod system...

Workaround: Switch your .xcodeproj format to go < 9.3 Compatible and CocoaPods will not use xcfilelist and incremental compilation should work.

I tried this for both. For cocoapod 1.7.5 and 1.8.0.beta.2 also. So switching my .xcodeproj to 8.0 or even 3.2 compatibility does not change anything in project - cocoapods still uses .xcfilelists after pod install. Also actually I do not understand what is the workaround expected to do. Allow to work properly with new build system?

@dnkoutso
Copy link
Contributor
dnkoutso commented Aug 28, 2019 •
edited
Loading

You told Xcode version does not matter for cocoapod system...

Yes that is true. CocoaPods does not find out your Xcode version. You control that. Therefore if you want to see your incrementa builds fixed with I/O paths you need to update to Xcode 11 Beta 6 and CocoaPods 1.8.0.beta.2 because CocoaPods 1.8.0.beta.2 is the only release that sets USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES to YES that Xcode 11 knows how to parse. This is why you need to also update to CocoaPods 1.8.0.beta.2.

I tried this for both. For cocoapod 1.7.5 and 1.8.0.beta.2 also. So switching my .xcodeproj to 8.0 or even 3.2 compatibility does not change anything in project - cocoapods still uses .xcfilelists after pod install. Also actually I do not understand what is the workaround expected to do. Allow to work properly with new build system?

I tried this locally and this was working for me. Try to also rm -rf Pods/ as a last resort or upload a sample app here demonstrating the issue with clear reproducible steps.

I am inclined to close this issue as I said in the previous comment CocoaPods has no way of identifying Xcode version and therefore is unable to warn.

@dnkoutso dnkoutso added the s1:awaiting input Waiting for input from the original author label Aug 28, 2019
@stale stale bot removed the s1:awaiting input Waiting for input from the original author label Aug 28, 2019
@dnkoutso dnkoutso added the s1:awaiting input Waiting for input from the original author label Aug 28, 2019
@Speakus
Copy link
Author
Speakus commented Sep 3, 2019

  1. There is way to detect which xcode supposed to use to build current project: https://github.com/fastlane/ci/blob/master/docs/xcode-version.md

  2. I made new issue which you requested: pod install does not respect decreasing Xcode compatibility version #9140

@stale stale bot removed the s1:awaiting input Waiting for input from the original author label Sep 3, 2019
@dnkoutso
Copy link
Contributor
dnkoutso commented Sep 3, 2019

.xcode-version is not supported by CocoaPods. It has been proposed but no RFC has been written.

@dnkoutso
Copy link
Contributor
dnkoutso commented Sep 3, 2019

Thanks for #9140. I continue to believe for this issue (#9056) we cannot do much.

@dnkoutso dnkoutso added s1:awaiting input Waiting for input from the original author and removed r:new build system Issues related to Xcode's new build system introduced in Xcode 9 labels Sep 3, 2019
@stale stale bot removed the s1:awaiting input Waiting for input from the original author label Sep 3, 2019
@Speakus
Copy link
Author
Speakus commented Sep 3, 2019

imho it's not so big deal to support .xcode-version but even if not then cocoapod always could check compatibilityVersion is less than Xcode 11

@dnkoutso
Copy link
Contributor
dnkoutso commented Sep 3, 2019

This is more about the new build system though not so much about the Xcode version. The new build system was supported in Xcode 9 as optional and was made the default in Xcode 10. Users may still choose to use the legacy one even in Xcode 11.

We could parse a workspace settings file to see but I think its unnecessary to add this logic.

@dnkoutso dnkoutso added the s1:awaiting input Waiting for input from the original author label Sep 3, 2019
@Speakus
Copy link
Author
Speakus commented Sep 3, 2019

The main issue described here we could get runtime issues with new build system without any warnings.
the issue: #8073 was not really fixed but suggested workaroud is not applied by default. So the #9056 is about to allow anyone (who uses cocoapod) to know about some issue is here - at least by seeing the warning.
So it allow developer to select one possible solution:

  1. switching to Xcode 11 and cocoapod 1.8.0.beta.2 (Inapplicable for Appstore builds at the moment)
  2. have workaround from Xcode10 (new build system) - if incremental build, Embed script doesn't run #8073 install! 'cocoapods', :disable_input_output_paths => true
  3. switch to legacy build system.

It's ok to select solution but hard to know the issue is there cause:
it's not reproduced for every build.
So warning from cocoapod could helps to many cocoapods clients.

@stale stale bot removed the s1:awaiting input Waiting for input from the original author label Sep 3, 2019
@dnkoutso dnkoutso removed this from the 1.8.0 milestone Sep 23, 2019
@dnkoutso dnkoutso added this to the 1.9.0 milestone Sep 23, 2019
@Speakus Speakus mentioned this issue Oct 12, 2019
Closed
@stale
Copy link
stale bot commented Dec 25, 2019

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

@stale stale bot added the s1:awaiting input Waiting for input from the original author label Dec 25, 2019
@Speakus
Copy link
Author
Speakus commented Dec 25, 2019

this one was not resolved

@stale stale bot removed the s1:awaiting input Waiting for input from the original author label Dec 25, 2019
@dnkoutso dnkoutso modified the milestones: 1.9.0, 1.10.0 Feb 25, 2020
@stale
Copy link
stale bot commented May 26, 2020

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

@stale stale bot added the s1:awaiting input Waiting for input from the original author label May 26, 2020
@Speakus
Copy link
Author
Speakus commented May 26, 2020

this one was not resolved yet

@stale stale bot removed the s1:awaiting input Waiting for input from the original author label May 26, 2020
@dnkoutso dnkoutso added the help wanted Help from new or existing contributors would be greatly appreciated! label May 26, 2020
@dnkoutso
Copy link
Contributor
dnkoutso commented Jun 22, 2020 •
edited
Loading

Xcode 12 Beta 1 seems to be fixing the issue permanently.

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

We have not yet verified it but I will and if so I will close this issue.

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

@dnkoutso
Copy link
Contributor

Confirmed with project in #8073 (comment) that this is fixed in Xcode 12 Beta 1.

This is no longer needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted Help from new or existing contributors would be greatly appreciated! s7:workaround available A workaround for the issue is available
Projects
None yet
Milestone
1.10.0
Development

No branches or pull requests
2 participants
@dnkoutso @Speakus
0