I added two files to a Xcode 5.1 vanilla single view project:
table.h
struct group {
int size;
};
table.c
#include "table.h"
and got this error:
Semantic issue
table.h:2:8: Redefinition of 'group'
"Previous definition" is:
iOS 7.1 > usr/include > grp.h
I am wondering why this grp.h is automatically included in my project. How can I not include it?
grp.h is one of the standard Unix-level files which defines some of the basic data structures; in this case, struct group is what gets returned by low-level C functions that deal with user permissions.
As for the question of why it's included in your project: When you create a new project in Xcode, it creates an include file that implicitly gets included in every .m or .c file in your project. In the project I just created to try this out, it's in the file browser in a group called Supporting Files, named something like [project]-Prefix.pch. Mine has the following contents:
#import <Availability.h>
#ifndef __IPHONE_5_0
#warning "This project uses features only available in iOS SDK 5.0 and later."
#endif
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#endif
That second to last line, #import <Foundation/Foundation.h>, then includes all the built-in Objective-C objects like NSObject, NSArray - and a bunch of things that work with the filesystem, and therefore need to be able to deal with permissions and group membership. One of those is then including grp.h.
So, back to your question - you can change your .pch file to not include Foundation/Foundation.h, and then manually include it wherever you need it.
But that will end up slowing down all your builds. The .pch file here is special; Xcode compiles it once and saves it in a binary format, so it doesn't have to parse the many thousands of lines of C code it expands to for every file you build.
My advice? Name your structure something else.
Normally of course it would be easier to change the naming of your struct, but as it comes from another library, here is my solution for you.
Turns out that if you allow your .pch file to include any of header files from iOS 7.1 > /usr/include then it will reference (include?) many more, including grp.h which causes the problem in your project.
So for example, if your .pch files contains this:
#import <Availability.h>
Then grp.h will cause the conflict.
If you comment out this line (and don't include any other headers from "iOS 7.1 > usr/include") then your project will compile.
As a test you can comment out <Availability.h> and add #import <cpio.h> and the result will be the same (although cpio.h is very small and don't reference any other header files).
I am not that good at understanding internals of compilation, so I can't explain why this happens but I traced down the issue to this file:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk/usr/include/module.map which seems to group together various Darwin header files.
Both iOS 7.0 and iOS 7.1 have this file while iOS 6.0 doesn't (which may explain why the same code worked on earlier iOS versions).
The good news is that although you need to remove /usr/include headers from your *.pch file, you can still include them in files where you actually need them and it won't break the compilation. That's probably because although the grp.h will eventually be included in those files, it won't be included in your table.c
grp.h has already declared a struct named 'group',
so you just need to rename your 'group' struct and everything will be ok.
(for example 'my_group')
Related
A similar question has been asked and answered here, however the solution provided does not solve my problem.
My Project has two targets: A Cocoa Framework (macOS) and a Cocoa Touch Framework (iOS).
The Frameworks share a lot of source files and headers, but there are files that are specific to each framework (due to platform differences).
In particular, both frameworks each have a class named ViewController.
On iOS, it is declared like this:
($(SRC_ROOT)/Platforms/iOS/ViewController/ViewController.h:)
#import <UIKit/UIKit.h>
#interface ViewController : UIViewController
...
On the Mac, like this:
($(SRC_ROOT)/Platforms/macOS/ViewController/ViewController.h:)
#import <Cocoa/Cocoa.h>
#interface ViewController : NSViewController
...
I also have a third class, Manager, that is common to both platforms.
It is just a subclass of NSObject and thus its header file only needs to import the platform-agnostic <Foundation/Foundation.h>.
But this class's methods interact with the aforementioned ViewController, so the implementation file imports that header:
($(SRC_ROOT)/Common/Manager.m:)
#import "Manager.h"
#import "ViewController.h" // <-- THIS
#implementation Manager
...
Now, when I build the iOS target everything is fine.
But when I try to build the macOS target, the iOS version of ViewController.h gets somehow imported and I get the following error:
Lexical or Preprocessor Issue - 'UIKit/UIKit.h' file not found
...pointing at the #import statement in Manager.m.
Some more information:
ViewController.h is a public header in both frameworks, and is included in the umbrella headers for both targets:
#import <MyFramework/ViewController.h>
Each version of the header has target membership set to the appropriate target.
For both targets, Header Search Paths and User Header Search Pathsis blank, and Always Search User Paths is NO.
I have tried to set Header Search Paths to each of the following values, to no avail:
$(SRC_ROOT)/Platforms/macOS/
$(SRC_ROOT)/Platforms/macOS/**
./Platforms/macOS/
./Platforms/macOS/**
I tried deleting the iOS version of the header temporarily, and the build succeeded. But after restoring the file and cleaning the build folder, it fails again.
How can I get Xcode to "see" the right version of the header, on the Mac target?
EDIT: I tried the same path values from point (4) for "Framework Search Paths". Same error.
UPDATE:
If I set the build setting Always Search User Paths to YES (the default is NO), my framework builds. I can even build a sample Mac app that links to it and it runs. However, I get the warning:
Warning: using 'ALWAYS_SEARCH_USER_PATHS = YES' while building targets
which define modules ('DEFINES_MODULE = YES') may fail. Please migrate
to using 'ALWAYS_SEARCH_USER_PATHS = NO'.
...but I read somewhere this would cause trouble down the line (can't find the post now).
UPDATE 2:
If, in addition, I change the build setting Defines Module to NO (as suggested by the warning), both the framework and the app that embeds it build succesfully, and the framework's classes are available (i.e., instantiable) from the app's code.
However, I fear this whole "not defining a module" business is going to cause trouble when I attempt to use my framework from an app written in Swift...?
I have a project that was started in Objective-C, and I am trying to import some Swift code into the same class files that I have previously written Objective-C in.
I have consulted the Apple docs on using Swift and Objective-C in the same project, as well as SO question like this, but still no avail: I continue to get the file not found error after putting in #import "NewTestApp-Swift.h" (NewTestApp is the name of the Product and module).
Here is what I have done so far:
In Define Modules, selected YES for the app.
Ensured that the Product Module name did not have any space in it (see screenshot below question)
I have tried using #import "NewTestApp-Swift.h" inside ViewController.m, ViewController.h and AppDelegate.m but none of them has worked.
What else am I doing incorrectly? Thanks for your help.
Screenshot of settings:
Errors that I am presently encountering:
I was running into the same issue and couldn't get my project to import swift into obj-c classes. Using Xcode 6, (should work for Xcode 6+) and was able to do it in this way....
Any class that you need to access in the .h file needs to be a forward declaration like this
#class MySwiftClass;
In the .m file ONLY, if the code is in the same project (module) then you need to import it with
#import "ProductModuleName-Swift.h"
Link to the apple documentation about it
https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/importing_swift_into_objective-c
If the Swift code is inside a Module (like in your case):
#import <ProductName/ProductModuleName-Swift.h>
If the Swift code is inside the project (mixed Swift and ObjC):
#import <ProductModuleName-Swift.h>
In your case, you have to add this line in the *.m file:
#import <NewTestApp/NewTestApp-Swift.h>
IMPORTANT: look at the "<" in the import statement
https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html
How I managed to import swift into objective-c:
Defines Module set to YES (on project - not on target)
Product Module Name set (on target - not on project)
In your ViewController.m import the swift code with:
#import "MyProductModuleName-Swift.h"
Add a swift file to your objective-c project (File -> New -> Swift) and Xcode will create the bridging header from objective-c to Swift but this is crucial for making it work the other way around too - apparently.
For the last piece in this puzzle thanks to Swiftoverload for making me aware of actually adding a Swift file via Xcode GUI and not just dragging and dropping existing swift-files into my project for making it work:
http://nikolakirev.com/blog/using-swift-in-objective-c-project
Using Xcode 8.2.1 and if you look at Project > Build Settings > Objective-C Generated Interface Header Name, there it shows only one header file named like Product-Swift.h
This means that instead of importing each modules separately from Objective-C .m file, using individual -Swift.h file, you just import one Product-Swift.h which aggregated all Swift modules.
I encountered the same problem by looking for traditional way of importing modules separately, but the current version of Xcode and Swift 3 changed it to use only one header for all module importing.
Spent an hour on this issue, following these steps will help you to understand what's missing:
Open Xcode preference and navigate to DerivedData folder
Search for "swift.h" in finder
If you can not find any project-swift.h file, this file haven't been generated. You usually need to add #objc to one of your swift class and successfully build the app, only then will Xcode generate this file
If you found "xxx-swift.h" file, make sure your import statement contains the correct name.
I was having problems importing Swift into an Objective-C project. In the end I looked into the Derivied Data folder to check what Xcode 7 was generating. The filename was completely different to the one I was expecting.
Once I had the actual filename I imported that and the project could build.
iOS - Swift.h file not found
[Mixing Objective-C and Swift]
<name>-Swift.h should be created by Xcode automatically if Swift code expose an API via #objc or #objcMembers[About]
Usually a location looks like
~/Library/Developer/Xcode/DerivedData/
ProductModuleName-foo/
Build/
Intermediates.noindex/
ProductModuleName.build/
Debug-iphoneos/
ProductModuleName.build/
DerivedSources/
ProductModuleName-Swift.h
It can be changed by
Project editor -> select a target -> Build Settings -> Per-configuration Intermediate Build Files Path
By default the value is $(PROJECT_TEMP_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
Importing the header file, i.e.
#import "<ProjectName>-Swift.h"
within the .h file generated an error, stating:
-Swift.h' file not found
and the build failed.
Instead use:
#import "<ProjectName>-Swift.h"
within the .m file, and even though the same error appears, running the project anyway suppresses the error.
The swift classes are then available within the .m file.
If Your App name have any special character then use _ for special character.
For Example if your App name is Name "Test App®"
Then you can import swift file by "Test_App_-Swift.h".
Space and ® is replace by _ while you are import.
Make sure your swift class has the public declaration, and extends NSObject:
public class MySwiftClass: NSObject {
//...
}
The import should work with quotes, not brackets, if the swift class is in the same project.
if you add a Swift File first, rememeber to add swift file to your target..., in the left column
Had faced the same problem with my team when was working on project using git. One developer hasn't updated Xcode to the last version (7.3) which was required for latest Swift 2.2 version. So, compiler hasn't recognized new Swift syntax and couldn't generate interface for Swift library (projectname-swift.h).
Check if Xcode version is the latest one!
DEFINE MODULES: YES
and import "ProjectName-Swift.h" in .m file of Obj-C class
This worked for me to access Swift classes in Obj-c.
I had the same problem with #import "myProj-Swift.h" not found, Xcode 12.3, the year is 2021.
It appears that unless a bridging header has been generated, it is not possible to import myProj-Swift.h.
My (reproducible) solution, when needing to add Swift to objective-C projects is to create (File - New File - Swift file) a dummy empty Swift file in my project. Xcode then asks whether to create a bridging header, to which I answer yes. This causes a "myProj-Bridging-Header.h" file to be added to my project, which is visible in the Project Navigator.
Once this is done, the error on #import "myProj-Swift.h" disappears.
After that I can delete the dummy file, and insert the needed Swift classes into the project.
The logic of generating a visible bridging header, but leaving the -Swift.h entirely invisible escapes me entirely. Never mind the challenge of trying to find out about this in the official documentation Importing Swift into Objective-C, which (to me inaccurately) states "You don’t need to do anything special to create the generated header".
It is probably a good idea to also mind the answer from #Sandeep Bhandari to this question - who says the -Swift.h file will only be generated if the project compiles successfully.
More info also in this and this question.
I ran into this problem after duplicating an existing target. When I tried to build with the duplicated target, the "ProductName-Swift.h file not found" error appears.
After going through the build settings in the new target, I found the value of the setting "Product Name" somehow is set as the same as the target name. After setting it with the correct one the error disappeared.
If your product name is TestApp-Dev then filename will TestApp_Dev-Swift.h
You can verify by going to the following location
~/Library/Developer/Xcode/DerivedData//Build/Intermediates.noindex/yourProjectbuild/Debug-iphonesimulator/MashreqMobileApp.build/DerivedSources
If you want same file name for each build schemes then go to
Build Settings to be the same across your modules/schemes. (set it to $(PROJECT_NAME)-Swift.h).
If project name is TestApp, then the file generated will TestApp-Swift.h and it will remain same across the schemes
During development, there might be a possibility that you would have any swift class that is not completely implemented due to which there might be some syntax errors.
The swift header file will be available for use only if all the swift files are error free.
Make sure there are no syntax errors in the swift files and then try to import the swift header in the objective - c file
I faced the problem with the name of project (target). It included symbol "-". So the decision was next: if name of project is "Test-App", then name of imported class is "Test_App-Swift.h"
If you have multiple target make sure that you have build all frameworks
Xcode 11
I ran into this problem when building on Xcode 11. Took me a bit to figure out what was wrong, but essentially, I had changed the "Display Name" setting on the Target's "General" tab instead of changing directly in the Info.plist file through the "Info" tab on the Target.
This resulted in Xcode 11.5 going through an rewriting/creating a bunch of brand new custom build settings and modifying the name of the app module and the built .app product. In this case the new display name also had a forward slash (/) character in it which may ultimately be why it wasn't building (see #Silversky Technology's answer).
Regardless, I resolved this by undoing all of Xcode 11.5's automatic changes to the project file and manually making the same change to the bundle display name in the Info.plist file and everything works perfectly.
I wish it would tell you that it was doing stuff like this before it just up and does it without your consent.
Target executable was missing a dependency on my (or any other in fact) framework.
Build Phases -> Dependencies must list the dependencies of a target to avoid intermittent errors: in my case debug
build was fine and automated Jenkins CI builds were failing.
A nightmare to debug considering Jenkins output produces
voluminous garbage that's a huge time pit to get through.
Default file:
#import <Foundation/Foundation.h>
#interface MyClass : NSObject
#end
My understanding is pre-compiled headers are included in every file. Why doesn't this import just go into the pre-compiled headers?
There is no guarantee that every project have a .pch file that import Foundation.h so Xcode need to generate it to make sure new files always compile.
Also some people think it is good style to include header even it is already included in .pch file. Because you know exactly what headers are needed by this file. It also allow people to disable prefix header if needed.
My Xcode 5 doesn't appear to be including it in every class (it is included in the .pch file). I agree with you that this makes more sense than including it everywhere. The answer to your question is probably "an oversight on Apple's part" :)
I am playing around with some of the new iOS 7 features and working with some of the Image Effects as discussed in the WWDC video "Implementing Engaging UI on iOS". For producing a blur effect within the source code for the session, UIImage was extended via a category which imports UIKit like so:
#import UIKit;
I think I saw something about this in another session video but I'm having trouble finding it. I'm looking for any background information on when to use this. Can it only be used with Apple frameworks? Are the benefits of using this compiler directive enough that I should go back and update old code?
It's a new feature called Modules or "semantic import". There's more info in the WWDC 2013 videos for Session 205 and 404. It's kind of a better implementation of the pre-compiled headers. You can use modules with any of the system frameworks in iOS 7 and Mavericks. Modules are a packaging together of the framework executable and its headers and are touted as being safer and more efficient than #import.
One of the big advantages of using #import is that you don't need to add the framework in the project settings, it's done automatically. That means that you can skip the step where you click the plus button and search for the framework (golden toolbox), then move it to the "Frameworks" group. It will save many developers from the cryptic "Linker error" messages.
You don't actually need to use the #import keyword. If you opt-in to using modules, all #import and #include directives are mapped to use #import automatically. That means that you don't have to change your source code (or the source code of libraries that you download from elsewhere). Supposedly using modules improves the build performance too, especially if you haven't been using PCHs well or if your project has many small source files.
Modules are pre-built for most Apple frameworks (UIKit, MapKit, GameKit, etc). You can use them with frameworks you create yourself: they are created automatically if you create a Swift framework in Xcode, and you can manually create a ".modulemap" file yourself for any Apple or 3rd-party library.
You can use code-completion to see the list of available frameworks:
Modules are enabled by default in new projects in Xcode 5. To enable them in an older project, go into your project build settings, search for "Modules" and set "Enable Modules" to "YES". The "Link Frameworks" should be "YES" too:
You have to be using Xcode 5 and the iOS 7 or Mavericks SDK, but you can still release for older OSs (say iOS 4.3 or whatever). Modules don't change how your code is built or any of the source code.
From the WWDC slides:
Imports complete semantic description of a framework
Doesn't need to parse the headers
Better way to import a framework’s interface
Loads binary representation
More flexible than precompiled headers
Immune to effects of local macro definitions (e.g. #define readonly 0x01)
Enabled for new projects by default
To explicitly use modules:
Replace #import <Cocoa/Cocoa.h> with #import Cocoa;
You can also import just one header with this notation:
#import iAd.ADBannerView;
The submodules autocomplete for you in Xcode.
Nice answer you can find in book Learning Cocoa with Objective-C (ISBN: 978-1-491-90139-7)
Modules are a new means of including and linking files and libraries into your projects. To understand how modules work and what benefits they have, it is important to look back into the history of Objective-C and the #import statement
Whenever you want to include a file for use, you will generally have some code that looks like this:
#import "someFile.h"
Or in the case of frameworks:
#import <SomeLibrary/SomeFile.h>
Because Objective-C is a superset of the C programming language, the #import state‐ ment is a minor refinement upon C’s #include statement. The #include statement is very simple; it copies everything it finds in the included file into your code during compilation. This can sometimes cause significant problems. For example, imagine you have two header files: SomeFileA.h and SomeFileB.h; SomeFileA.h includes SomeFileB.h, and SomeFileB.h includes SomeFileA.h. This creates a loop, and can confuse the coimpiler. To deal with this, C programmers have to write guards against this type of event from occurring.
When using #import, you don’t need to worry about this issue or write header guards to avoid it. However, #import is still just a glorified copy-and-paste action, causing slow compilation time among a host of other smaller but still very dangerous issues (such as an included file overriding something you have declared elsewhere in your own code.)
Modules are an attempt to get around this. They are no longer a copy-and-paste into source code, but a serialised representation of the included files that can be imported into your source code only when and where they’re needed. By using modules, code will generally compile faster, and be safer than using either #include or #import.
Returning to the previous example of importing a framework:
#import <SomeLibrary/SomeFile.h>
To import this library as a module, the code would be changed to:
#import SomeLibrary;
This has the added bonus of Xcode linking the SomeLibrary framework into the project automatically. Modules also allow you to only include the components you really need into your project. For example, if you want to use the AwesomeObject component in the AwesomeLibrary framework, normally you would have to import everything just to use the one piece. However, using modules, you can just import the specific object you want to use:
#import AwesomeLibrary.AwesomeObject;
For all new projects made in Xcode 5, modules are enabled by default. If you want to use modules in older projects (and you really should) they will have to be enabled in the project’s build settings. Once you do that, you can use both #import and #import statements in your code together without any concern.
#import Module(ObjC) or Semantic import
instead of usual module using
//as example
#include <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
History:
[#include -> #import] -> [Precompiled Headers .pch] -> #import Module(ObjC); -> [import Module(Swift)]
It is a part of LLVM Modules
#import <module_name>; declaration says to compiler to load(instead of compile) a precompiled binary of module which decrease a building time. Previously compiler compiled dependency every time when runt into it but now it should be compiled beforehand and just loaded
//previously
run into dependency -> compile dependency
run into dependency -> compile dependency
//#import
compile dependency
run into dependency -> load compiled binary
run into dependency -> load compiled binary
[Modulemap] - bridge between module and headers
Xcode
Enable Modules(C and Objective-C)(CLANG_ENABLE_MODULES) - CLANG #include, #import directives are automatically converted to #import that brings all advantages. Modulemap allows to do it seamless because contains a map between headers and sub/modules
Pass -fmodules
#include, #import -> #import
Link Frameworks Automatically(CLANG_MODULES_AUTOLINK) - enables system modules auto linking. Requires activated CLANG_ENABLE_MODULES. Auto-linking allows to pass -framework <framework_name> based on #import, #import(Objective-C), import(Swift)
If NO - passes -fno-autolink flag
CLANG_ENABLE_MODULES == NO and CLANG_MODULES_AUTOLINK == NO
If you want to handle system(#import <UIKit/UIKit.h>) linking manually(instead of auto-linking) you have two variants:
Add dependency into General -> Frameworks and Libraries or Frameworks, Libraries, and Embedded Content
Build Settings -> Other Linker Flags(OTHER_LDFLAGS) -> -framework <module_name>
Next error will be thrown if:
Undefined symbol: _OBJC_CLASS_$_UIView
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_UIView", referenced from:
objc-class-ref in ClassB.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
CLANG_ENABLE_MODULES is disabled
CLANG_MODULES_AUTOLINK is disabled and no manual linking
Reverse engineering
otool -l <binary>
//-l print the load commands
//find LC_LINKER_OPTION
//cmd LC_LINKER_OPTION
It currently only works for the built in system frameworks. If you use #import like apple still do importing the UIKit framework in the app delegate it is replaced (if modules is on and its recognised as a system framework) and the compiler will remap it to be a module import and not an import of the header files anyway.
So leaving the #import will be just the same as its converted to a module import where possible anyway
It seems that since XCode 7.x a lot of warnings are coming out when enabling clang module with CLANG_ENABLE_MODULES
Take a look at Lots of warnings when building with Xcode 7 with 3rd party libraries
There is a few benefits of using modules. You can use it only with Apple's framework unless module map is created. #import is a bit similar to pre-compiling headers files when added to .pch file which is a way to tune app the compilation process. Additionally you do not have to add libraries in the old way, using #import is much faster and efficient in fact. If you still look for a nice reference I will highly recommend you reading this article.
I'm using AddThis to add sharing options in my iOS app.
I have imported the classes and added the -fno-objc-arc flag to all the imported classes since they don't use ARC.
However, when I try to run the app I get a slew of Parse Issues such as:
Expected identifier or '('
Unknown type name 'NSString'
Unknown type name 'Protocol'
...
These errors occur in NSObjCRuntime, NSZone, and NSObject. I have the requisite frameworks included as well. Any ideas?
Including this image if it helps:
I had the same issue on my project when I was trying to mix C code (.h and .c) with Objective-C code. Found the reason of the issue:
Check your .pch file to make sure every Objective-C framework #import (such as #import <UIKit/UIKit.h>) is enclosed in:
#ifdef __OBJC__
#endif
If they're outside of this conditional scope, the compiler will try to import Objective-C frameworks into C source code.
I just changed the filename of Base64Transcoder.c to Base64Transcoder.m, and now the project compiles. I have no idea why this fixes the problem, but it works.
I had the same issue, using C and C++ code with objective C, and i doesnt have a .pch
The easiest solution was to go into your build settings -> Custom Compiler Flags and set the "Other C Flags" to "-x objective-c" and set the "Other C++ Flags" to "-x objective-c++"
this will do the trick with xCode 7.2
I have had the same problem when my project contained .cpp files.
If .cpp file doesn't contain ObjectiveC frameworks(e.g. ) it has to 'Default-C++ Source' type
,
but if .cpp file has ObjectiveC frameworks - it must be as 'Objective-C++ Source'
TLDR: if your PCH file is OK, look through your CPP file headers to see if you've accidentally included any headers for Objective C objects.
The Details:
I got this because I had accidentally included an Objective-C class header in a C++ class header, indirectly. The structure was this:
Compass.h defined a pure Objective C class.
ActionTracker.h defined a C++ class that understood Objective C constructs (via ActionTracker.mm).
HelloWorld.h defined a purely C++ class.
In my original setup, HelloWorld.h included ActionTracker.h, but this was OK as ActionTracker.h didn't yet contain Compass.h. Later, I changed my code and included Compass.h in ActionTracker.h, which then pulled it into HelloWorld.h and I got these errors.
I had this same problem when I tried to move the info.plist file from one directory to another.
This somehow triggered XCode to edit the build phases for that target and significantly increased the amount of "Compile Sources" and "Copy Bundle Resources".
Luckily my project has multiple targets that I use for testing, (i.e. App Demo, App Dev, App Local, App 1.1, App 1.2 etc)
So I just duplicated one of the unaffected targets and renamed it (also renamed the bundle identifier and the build scheme) and this obviously fixed the problem for me since it's not the whole project that was affected but only that specific target.
If you want to try my solution, try to create a new target from scratch, or duplicate and rename any of your un-affected targets.