xcconfigs / xcconfigs Goto Github PK

Hi, @jspahrsummers

I'm getting this during "carthage update --platform iOS"

Any Idea of how to solve it?

New in Xcode 9

I checked master in both Xcode 8 and Xcode 8.1 beta and there are no new warnings or issues. I feel like this is a good spot to open a new release.

From the docs:

"Warn about repeatedly using a weak reference without assigning the weak reference to a strong reference. This is often symptomatic of a race condition where the weak reference can become nil between accesses, resulting in unexpected behavior. Assigning to temporary strong reference ensures the object stays alive during the
related accesses. "

Common thing should be to store a weak ref into a strong one, then work with the strong reference. Still, sometimes this just doubles the LOC, e.g. when sending a single message to a delegate.
This might have been the reason to introduce CLANG_WARN_OBJC_REPEATED_USE_OF_WEAK, which only barfs when a weak ref is used multiple time in the same block, vs. CLANG_WARN_OBJC_RECEIVER_WEAK which warns on every usage of weak refs.

What do you think? Enable it in Base/Common.xcconfig?

Hi,

in the Xcode 6.3 release notes Apple states the following.

ARM64 Intrinsics Changes
• The argument ordering for the arm64 vfma/vfms lane intrinsics has changed. Since that change may not trigger compile-time errors but will break code at run-time, we are staging the transition to make it less risky.
By default, the compiler will now warn about any use of those intrinsics and will retain the old behavior. As soon as possible, you should adopt the new behavior and define the USE_CORRECT_VFMA_INTRINSICS macro to 1 to inform the compiler of that. You can also define that macro to 0 to silence the warnings and keep the old behavior, but do not leave your code in that state for long, since we plan to remove support for the old behavior in a future release. (17964959)

I think it would be a good idea to include the USE_CORRECT_VFMA_INTRINSICS=1 definition. Thoughts?

Are these settings self-sufficient? Or is it recommended to use these settings along with the default settings that Xcode generates for a new project? If these are self-sufficient, I'm assuming the settings defined in Xcode should be deleted.

New in Xcode 9

Xcode 7.2 warns that GCC_NO_COMMON_BLOCKS is not enabled.

Hi, I'm using in tvOS app.

I found that ENABLE_TESTABILITY is not configured.
Is there any reason for this, or do you want me to add that to Debug.xcconfig(YES) and Release.xcconfig(NO) ?

Also found these Xcode default settings are not set either.

CLANG_CXX_LANGUAGE_STANDARD="gnu++0x"
CLANG_CXX_LIBRARY="libc++"
GCC_NO_COMMON_BLOCKS=YES
MTL_ENABLE_DEBUG_INFO=  //YES in debug, NO in release

It would be great to see BITCODE_GENERATION_MODE set to bitcode for all relevant release binaries when ENABLE_BITCODE is set. Currently, default behavior in Xcode differs between building and archiving:

Carthage/Carthage#535 (comment)

Hoping for a new tag, specifically with the CLANG_WARN_NULLABLE_TO_NONNULL_CONVERSION warning that was added somewhat recently. Thanks!

Given Xcode 10.2 was released I browsed though the warnings list today. And found some new things (stuff I haven't seen before):

// Warn about assigning integer constants to enum values that are out of the range of the enumerated type.
CLANG_WARN_ASSIGN_ENUM = YES

// Warns when a quoted include is used instead of a framework style include in a framework header.
CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER = YES

// Warn when a source file does not end with a newline.
GCC_WARN_ABOUT_MISSING_NEWLINE = YES

// Check for Grand Central Dispatch idioms that may lead to poor performance.
CLANG_ANALYZER_GCD_PERFORMANCE = YES

// Warn about implicit ownership types on Objective-C object references as out parameters. For example, declaring a parameter with type `NSObject**` will produce a warning because the compiler will assume that the out parameter's ownership type is `__autoreleasing`
CLANG_WARN_OBJC_EXPLICIT_OWNERSHIP_TYPE = YES

Following seem to be gone as of Xcode 10.2?

CLANG_WARN_NULLABLE_TO_NONNULL_CONVERSION
CODE_SIGNING_REQUIRED

Will have a more closer look tomorrow, but those came up first.
Any other?

Before I raise a PR for this:

Currently, the platform names are inconsistent. watchOS and tvOS and iOS match the usual platform names, but not Mac OS X. This sort of bothers me and I'd like to rename it to macOS for consistency.

Not sure how people will feel about having to relink to the newly named files after pulling these changes though.

Thoughts?

Any plans on supporting tricky case of CocoaPods integration?

I've been bitten by it recently and had to jump hoops and dance around xcconfig inheritance, utilise cocoapods post install hooks, etc. to get some setup working.

Would be nice to have pods supported in this repo.

New in Xcode 9

I'm using xcconfigs via Mantle. I'm also using RAC.

I can build and archive using Xcode (Build uses Debug configuration, Archive uses AdHoc configuration), and with xcodebuild or xctool with -configuration Debug. However, with -configuration AdHoc, xcodebuild/xctools builds fail saying ReactiveCocoa/ReactiveCocoa.h is not found.

My Phoenix-Debug/Phoenix-AdHoc xcconfig files just #include iOS-Application and add code signing parameters.

Any idea what the issue is? I'm using Xcode 5.1.1.

Any plan to release new version for #84 ?

http://stackoverflow.com/a/34040901/354018

The last tag was 0.8.1 back in May 2015

Carthage 0.12 seems to be having trouble resolving dependencies against "master" but I can't peg it to a tag because there is nothing more recent than 0.8.1.

There have been many changes since the 0.10 tag for Xcode 8: 0.10...master

The warning GCC_WARN_UNUSED_PARAMETER could be added as well. iOS default is NO.

Sorry, I've a Xcode beginner, but I try to bring https://github.com/gitx/objective-git back to live and want support Apple Silicon.
Doing so, I update xcconfig to recent commit, to have this ff66306
But I run into this gitx/objective-git#48

/Users/hannes/git/gitx/External/objective-git/Carthage/Checkouts/xcconfigs/Mac OS X/Mac-StaticLibrary.xcconfig:8:1: error: could not find included file 'This configuration file ('Mac OS X/Mac-StaticLibrary.xcconfig') is deprecated. Please use 'macOS/macOS-StaticLibrary.xcconfig' instead.' in search paths
/Users/hannes/git/gitx/External/objective-git/Carthage/Checkouts/xcconfigs/Mac OS X/Mac-StaticLibrary.xcconfig:8:1: error: could not find included file 'This configuration file ('Mac OS X/Mac-StaticLibrary.xcconfig') is deprecated. Please use 'macOS/macOS-StaticLibrary.xcconfig' instead.' in search paths
/Users/hannes/git/gitx/External/objective-git/Carthage/Checkouts/xcconfigs/Mac OS X/Mac-StaticLibrary.xcconfig:8:1: error: could not find included file 'This configuration file ('Mac OS X/Mac-StaticLibrary.xcconfig') is deprecated. Please use 'macOS/macOS-StaticLibrary.xcconfig' instead.' in search paths
/Users/hannes/git/gitx/External/objective-git/Carthage/Checkouts/xcconfigs/Mac OS X/Mac-Framework.xcconfig:8:1: error: could not find included file 'This configuration file ('Mac OS X/Mac-Framework.xcconfig') is deprecated. Please use 'macOS/macOS-Framework.xcconfig' instead.' in search paths
/Users/hannes/git/gitx/External/objective-git/Carthage/Checkouts/xcconfigs/Mac OS X/Mac-Framework.xcconfig:8:1: error: could not find included file 'This configuration file ('Mac OS X/Mac-Framework.xcconfig') is deprecated. Please use 'macOS/macOS-Framework.xcconfig' instead.' in search paths
/Users/hannes/git/gitx/External/objective-git/Carthage/Checkouts/xcconfigs/Mac OS X/Mac-Framework.xcconfig:8:1: error: could not find included file 'This configuration file ('Mac OS X/Mac-Framework.xcconfig') is deprecated. Please use 'macOS/macOS-Framework.xcconfig' instead.' in search paths
** ARCHIVE FAILED **

The suggested solution is not understandable for me. -sorry-

What should I do here exactly to make it work ? Thank you !

This setting could be included and set to YES.

It would be cool to have a new release. A lot has happened since the last tag. It would also be cool to keep tags in sync with Xcode versions (as needed) since those releases change how build settings are interpreted.

From the release notes of the newest Xcode 9.3 beta 4:

When an .xcconfig file contains multiple assignments of the same build setting, later assignments using $(inherited) will inherit from earlier assignments when using the new build system. The old build system discards all except the last assignment. This can cause the evaluated result to be different if $(inherited) is used in the value. You can enable a setting to emit a warning if any of these cases are found by running defaults write com.apple.dt.XCBuild EnableCompatibilityWarningsForXCBuildTransition YES. (37833468)

This could be problematic when an xcconfig should overwrite a build setting that was set in another imported xcconfig.
I have not yet checked if this is already the case for this repo alone, but we definitely have that issue in our app, as we have our own xcconfigs where we import the xcconfigs from this repo vanilla, and overwrite specific build settings.