unexpected '#' in program in test target - ios

I have string constant declared as below. This code compilers in normal app debug and release target. But in app's test target (Ctrl + U), I got error that unexpected '#' in program in test target. Using xcode 7.
Modules are enabled as answered in this question.
HeaderA.h
#define URL_A "http://www.example.com/service"
HeaderB.h
#define URL_AC #URL_A
Got error here, unexpected '#' in program. Expanded from macro #URL_AC
Modules are enabled as answered in this question.
Used in an .m file as,
NSURL * url = [NSURL URLWithString:URL_AC];
Even declaration of
#define URL_AC #"https://www.example.com/service?format=json"
got 'Use of undeclared identifier URL_AC' compiler error.

I found the problem. The 'define' have some #ifdef macros. And this is controlled using preprocessor declaration in the build settings. In my test target it was not defined. When I defined it, compiler gets the 'define' and all errors gone.
#if defined(TEST0)
#define URL0 "http://www.example.com"
#elif defined(TEST1)
#define URL1 "http://www.example2.com"
#endif

Related

linker command failed with exit code 1 after I upgrade to Xcode 7

After I upgraded to El Capitan and Xcode 7, I cannot build my app. I keep getting duplicate symbols on all of my global variables. Please help.
enter image description here
//Global.h
#ifndef Global_h
#define Global_h
extern NSInteger pickerConstantOne, pickerConstantTwo,numberOfDays, monthOfToday;
NSInteger pickerConstantOne, pickerConstantTwo,numberOfDays, monthOfToday;
#endif /* Global_h */
You have misdeclared those variables; remove this statement from the header:
NSInteger pickerConstantOne, pickerConstantTwo,numberOfDays, monthOfToday;
and move it into a .m file.
You should also review exactly why you are using global variables in the first place as you certainly don't need to be.

What can be the cause of "use of undeclared identifier LOG_LEVEL_VERBOSE" message

I'm trying to configure cocoalumberjack and when I've added ddLogLevel set to LOG_LEVEL_VERBOSE XCode throws "use of undeclared identifier" error. Why is that? How to avoid?
This question indicates that clearing DerivedData and restarting Xcode solves this kind of error.
However you should not include variables in the pre-compiled header as it will be included in every source file and prefix files are somewhat complicated compared to normal header files.
Better is to have use a Constants.h file which contains:
extern int ddLogLevel;
and #import that into your prefix file.
Then create an Constants.m with:
int ddLogLevel =
#ifdef DEBUG
LOG_LEVEL_VERBOSE;
#else
LOG_LEVEL_ERROR;
#endif
This way there is only one instance of ddLogLevel and it can be easily changed at runtime if necessary.
See this question for hints about prefix file best practices.
What solved it for me was changing #import <CocoaLumberjack/CocoaLumberjack.h> to #import CocoaLumberjack;, when using Xcode 8.0 for an Objective-C project.
Droppy’s post is correct and I recommend doing that, but I would like to address the question directly. There is a flaw in your code that may be resulting in the error.
LOG_LEVEL_VERBOSE is defined in DDLog.h. Your header file only imports DDLog.h if __OBJC__ is defined, but uses LOG_LEVEL_VERBOSE without this condition. Therefore if __OBJC__ is not defined, LOG_LEVEL_VERBOSE will be undefined.
Why would __OBJC__ not be defined? The prefix header is prepended to C, C++, Objective-C and Objective-C++ files. Since __OBJC__ is only defined for the latter two, if there are any C or C++ files in your project then the error will occur.
Knowing this, it is clear the ddLogLevel definition should be inside the #ifdef __OBJC__ check. However, you should do what Droppy said, and also make sure all Objective-C imports go inside the check.
For people who use "CocoaLumberjack 2.X" and still facing same issue after pod update, please try to import "DDLegacyMacros.h".
For prefix file users, try something like this :
#ifdef __OBJC__
...
...
#import <DDTTYLogger.h>
#import <DDLog.h>
#import <DDLegacyMacros.h>
#endif
Hope this helps someone else.

In absence of preprocessor macros, is there a way to define practical scheme specific flags at project level in Xcode project

Before swift I would define a set of schemes for alpha, beta, and distribution builds. Each of these schemes would have a set of macros that were defined to gate certain behaviors at the project level. The simplest example is the DEBUG=1 macro that is defined by default for all Xcode projects in the default scheme for the Run build. One could query #ifdef DEBUG ... and make decisions in the code accordingly, even compiling out non-necessary code.
It seems that this type of configurational gating is not as easy using swift, as macros are not supported. Can someone suggest a comparable approach, I don't care if the code is compiled out, per se. I would like to gate features based on build scheme, though.
In Swift you can still use the "#if/#else/#endif" preprocessor macros (although more constrained), as per Apple docs. Here's an example:
#if DEBUG
let a = 2
#else
let a = 3
#endif
Now, you must set the "DEBUG" symbol elsewhere, though. Set it in the "Swift Compiler - Custom Flags" section, "Other Swift Flags" line. You add the DEBUG symbol with the -D DEBUG entry.
(Build Settings -> Swift Compiler - Custom Flags)
As usual, you can set a different value when in Debug or when in Release.
I tested it in real code; it doesn't seem to be recognized in a playground.
We ran into an issue with not wanting to set swift compiler flags because we didn't want to have to set them and keep them up to date for different targets etc. Also, in our mixed codebase, we didn't want to make remember to set our flags appropriately all the time for each language.
For ours, we declared a file in ObjC
PreProcessorMacros.h
extern BOOL const DEBUG_BUILD;
In the .m
PreProcessorMacros.m
#ifdef DEBUG
BOOL const DEBUG_BUILD = YES;
#else
BOOL const DEBUG_BUILD = NO;
#endif
Then, in your Objective-C Bridging Header
#import "PreProcessorMacros.h"
Now, use this in your Swift codebase
if DEBUG_BUILD {
println("debug")
} else {
println("release")
}
This is definitely a workaround, but it solved our problem so I posted it here in the hopes that it will help. It is not meant to suggest that the existing answers are invalid.
More swifty solution to Logans method. Set -D DEBUG in Other Swift Flags of Swift Compiler - Custom Flags section in build settings of your target.
Then declare following method in global scope:
#if DEBUG
let isDebugMode = true
#else
let isDebugMode = false
#endif
Now use it as
if isDebugMode {
// Do debug stuff
}
For me, set the debug item of "Active Compilation Condition" to "DEBUG" worked.
Then using DEBGU key work in #IF DEBUG works in debug mode and #ELSE in release mode:
Select your target,
In Build Setting tab search for "Active Compilation Condition",
Set the value of its "Debug" item to "YourKeyWord",
Use simply as follow:
#if DEBUG
print("You'r running in DEBUG mode!")
#else
print("You'r running in RELEASE mode!")
#endif
Swift compiler directives
You can use next compiler directive
#if <some_key>
//logic 1
#else
//logic 2
#endif
//pre Xcode v8
Other Swift Flags(OTHER_SWIFT_FLAGS) = -D <some_key>
-D DEBUG
//from Xcode v8
Active Compilation Conditions(SWIFT_ACTIVE_COMPILATION_CONDITIONS) = <some_key>
DEBUG
I'm working in a mixed language code base where the obj-c code uses a macro to send debug messages to the console (and that macro relies on our debug preprocessor flag). I wanted to be able to call that same macro in the swift code...
I created a class method on one of my obj-c classes that is a wrapper around that macro.
I added that obj-c header to our bridge header file.
Now my swift code calls that class method as a "proxy" to the obj-c macro.
It's mildly annoying that I can't just call the macro straight up in the swift code, but at least now I only have one place in the project to worry about turning my debug flag on/off.

Operator 'defined' requires an identifier ios

I've below code in my project dlog should print the values in console if isConsoleLogActive is YES.
It gives error like Operator 'defined' requires an identifier
#if defined ([Util isConsoleLogActive])// Operator 'defined' requires an identifier in this line
#define DLog(...) NSLog(__VA_ARGS__)
#define DTrace() NSLog(#"%s", __PRETTY_FUNCTION__)
#else
#define DLog(...) /* */
#define DTrace() /* */
#endif
if I use the same code([Util isConsoleLogActive]) in my .m it works perfectly fine. I face this issue only in #define
What could be the issue. Please give me some idea.
The various commands that start with # are preprocessor directives. These get executed before the compilation phase at build time, before your application actually executes. You should use the preprocessor directives to conditionally include different code in your application based on build configuration. The preprocessor, however, is the wrong way to handle conditional execution on a specific platform at runtime; for that, you want your standard "if...else" logic.
If your goal with that statement is to determine if the given selector exists, try respondsToSelector, instead.
Result of
[Util isConsoleLogActive]
is not known at compile-time. So you can not use it with '#if defined'.

Literal #YES not working in iOS 5 / Xcode 4.4

New Xcode 4.4 is out and it should support literals like
#42
#"String"
#23.0L
#{ #"key" : obj } and
#[obj1, obj2]
and it should also support #YES and #NO, which isn't working when targeting latest iOS 5 (and prior).
After compiling it show the error message:
Unexpected type name 'BOOL': expected expression
I know you can fix it by typing #(YES) and #(NO). But I want to know the reason why it isn't working as expected.
The reason is Apple forgot the parentheses here:
#define YES (BOOL)1
This will be fixed in iOS 6 SDK:
#define YES ((BOOL)1)
In the meantime you must type #(YES).
This is useful for information about literals.
A commenter on this answer also points out:
There is one small thing I'd like to warn about. Literal bools are also not supported
because of this. However, a quick fix that I implemented was adding
this to the beginning of one of my common headers (in an iOS project)
#ifndef __IPHONE_6_0
#if __has_feature(objc_bool)
#undef YES
#undef NO
#define YES __objc_yes
#define NO __objc_no
#endif
#endif
#phix23s answer seems to be more to the point. You should accept that.
This was worth adding from comments:
It should be noted that this needs to be done after the #import . If one puts these #defines in their Prefix.pch, they should make sure to import Foundation earlier in the pch

Resources