8000 Avoid 'Unspecified' value for SWIFT_VERSION build settings by heyzooi · Pull Request #7109 · CocoaPods/CocoaPods · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Avoid 'Unspecified' value for SWIFT_VERSION build settings #7109

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
wants to merge 6 commits into from

Conversation

heyzooi
Copy link
@heyzooi heyzooi commented Oct 6, 2017
  • Avoid 'Unspecificed' value for SWIFT_VERSION build settings
  • Making Swift 3.2 the default value since this is the minimum version supported by Xcode 9

CHANGELOG.md Outdated
@@ -50,6 +50,10 @@ To install release candidates run `[sudo] gem install cocoapods --pre`
[Dimitris Koutsogiorgas](https://github.com/dnkoutso)
[#7081](https://github.com/CocoaPods/CocoaPods/issues/7081)

* Avoid 'Unspecificed' value for SWIFT_VERSION build settings and make 'Swift 3.2' the default value
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo, Unspecified

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks... fixing it!

@heyzooi heyzooi changed the title Avoid 'Unspecificed' value for SWIFT_VERSION build settings Avoid 'Unspecified' value for SWIFT_VERSION build settings Oct 6, 2017
@@ -470,7 +470,7 @@ def install_pod
next unless (native_target = pod_target.native_target)
native_target.build_configuration_list.build_configurations.each do |build_configuration|
(build_configuration.build_settings['OTHER_CFLAGS'] ||= '$(inherited)') << ' -Wincomplete-umbrella'
build_configuration.build_settings['SWIFT_VERSION'] = swift_version if pod_target.uses_swift?
build_configuration.build_settings['SWIFT_VERSION'] = swift_version if pod_target.uses_swift? && !swift_version.nil?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a test that covers the !swift_version.nil? part? If not can you please add one?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not a ruby developer, i will try my best to write unit tests

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not a problem! There are plenty of examples around the *_spec.rb for the class you are writing a test for you can cargo cult from.

Copy link
Author
@heyzooi heyzooi Oct 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm trying to figure out how to run unit tests in ruby. reading this tutorial here: https://code.tutsplus.com/tutorials/ruby-for-newbies-testing-with-rspec--net-21297
but i'm getting this error:

/Users/victor/.rvm/gems/ruby-2.0.0-p648/gems/rspec-core-3.6.0/lib/rspec/core/formatters.rb:206:in `built_in_formatter': cannot load such file -- rspec/core/formatters/progress_formatter (LoadError)

googling it to figure out how to fix it. if know the solution, please let me know please.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm... i figured how to run bundle exec bacon ...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can also run bundle exec rake spec or bundle exec rake spec:unit for only unit tests

8000

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@heyzooi can you provide a case where the part !swift_version.nil? can be true?

@@ -100,7 +100,7 @@ def self.add_xctest_search_paths(target)
#
def self.add_swift_version(target, swift_version)
target.build_configurations.each do |configuration|
configuration.build_settings['SWIFT_VERSION'] = swift_version
configuration.build_settings['SWIFT_VERSION'] = !swift_version.nil? ? swift_version : Validator::DEFAULT_SWIFT_VERSION
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needs a test

Copy link
Member
8000

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit pick here, rather than checking for nil in each loop, could the desired value be extracted to before the loop? Something like

version_to_set = swift_version || Validator::DEFAULT_SWIFT_VERSION
target.build_configurations.each do |configuration|
    configuration.build_settings['SWIFT_VERSION'] = version_to_set
end

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure! let me do that

@@ -25,6 +25,9 @@ def initialize(path, skip_initialization = false,
@pods = new_group('Pods')
@development_pods = new_group('Development Pods')
self.symroot = LEGACY_BUILD_ROOT
root_object.build_configuration_list.build_configurations.each do |config|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we care for the entire project to set this value? It seems that each and every other pod target that uses swift should use a value now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you don't specify a value for the SWIFT_VERSION build settings, Xcode will not compile, so the idea here was to set a default version and allow each pod to override the default version as needed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@heyzooi doesnt each pod that uses swift automatically get assigned a version? I am still not 100% convinced we need to be changing the project configuration in this PR.

@@ -894,10 +894,10 @@ def test_swiftpod_with_dot_swift_version(version = '3.1.0')
end

describe '#swift_version' do
it 'defaults to Swift 3.0' do
it 'defaults to Swift 3.2' do
Copy link
Member
@amorde amorde Oct 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a test right above this that contains a warning message starting with The validator for Swift projects uses Swift 3.0 by default - could that test (and possibly the code that generates that warning) be updated as well?

Edit: this is now fixed

@heyzooi
Copy link
Author
heyzooi commented Oct 6, 2017

hey guys, how do I link the cocoapods-integration-specs submodule to this PR CocoaPods/cocoapods-integration-specs#125?

@amorde
Copy link
Member
amorde commented Oct 6, 2017

@heyzooi That PR needs to be accepted before this one, then update the git submodule reference to point to the latest commit

@@ -1,8 +1,12 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this file need to change?

@dnkoutso
Copy link
Contributor

This change we should overall land but there are still a few questions remaining before we do so.

@@ -99,8 +99,9 @@ def self.add_xctest_search_paths(target)
# @return [void]
#
def self.add_swift_version(target, swift_version)
version_to_set = !swift_version.nil? ? swift_version : Validator::DEFAULT_SWIFT_VERSION
Copy link
Contributor
@dnkoutso dnkoutso Oct 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this belongs in this method. If it does it most certainly needs documentation update.

I still need to clearly understand a case in which in validator.rb...

    # @return [String] the SWIFT_VERSION to use for validation.
    #
    def swift_version
      return @swift_version if defined?(@swift_version)
      if version = dot_swift_version
        @swift_version = version
      else
        DEFAULT_SWIFT_VERSION
      end
    end

...can return nil? Is it if the contents of the .swift-version file are empty?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if .swift-version is empty, it returns nil, and goes to DEFAULT_SWIFT_VERSION

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. F438 Learn more.

So yes I don't see the reason why we are doing a nil? check here and in the other place, @heyzooi

@dnkoutso
Copy link
Contributor

@heyzooi I am going to decline this PR in favor of #7136. I gave you credit in this other PR.

I verified that with Xcode 9 I no longer see "Unsupported" version for Swift and instead defaults to 3.2.

I do not think the remaining changes in this PR as necessary.

@dnkoutso dnkoutso closed this Oct 13, 2017
@piemonte
Copy link

as of recent, i've encountered this issue with the following project:

📎 https://github.com/piemonte/player

even though i have a .swift-verision and properly specified project file, linting still seems to fail. i haven't been able to push the latest release.

@dnkoutso
Copy link
Contributor

@piemonte are you on 1.4.0.beta.1? There was a regression in setting Swift version entirely for the project which was fixed in #7131 but it has not been released yet.

@piemonte
Copy link

@dnkoutso ah, yes, i am. you're awesome, thanks for the link.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
31C9
0