In Xcode 5, I create a project named myproject, in the project's Build Settings I can set Objective-C Automatic Reference Counting to YES in order to use ARC. Then there is a target also named myproject, what if in the target's Build Settings page I set Objective-C Automatic Reference Counting to NO, does this mean eventually I'll use manual memory management? Do I have to set both of the two boolean flag to the same value, either YES for ARC or NO for manual memory management?
Project settings will get applied to all your targets.
Individual target settings will override project settings.
SO if you put YES in project settings and NO in only one particular target..effectively your boolean value is NO for that target. And it'll remain YES for all other targets (where you haven't modified the settings)
Yes, both should have the same value (YES or NO). The first is for the project (so xcode warns you when you write code not compatible with arc) and the second in the target settings is for the compiler, so the compiler can add all the retain/release code for you if you have ARC YES.
Related
I want to force Xcode to use a custom compiler ('clang-llvm' build from the src) so I can use the clang plugin. My Xcode version is 7.3.1.
People say it is possible with custom toolchains. I didn't make a research on them because easier solution worked well for me:
It is also possible to run frontend plugins directly by setting appropriate "build settings" of Xcode. (Several ways to do this, you can set them on the command line for instance: xcodebuild build FOO=bla.) Here are a few build settings that I found useful to inject C flags:
OTHER_CFLAGS, OTHER_CPLUSPLUSFLAGS or to replace the compiler(s) and linker(s):
CC, CPLUSPLUS, LD, LDPLUSPLUS, LIBTOOL
The same approach works to control the "analyze" action: CLANG_ANALYZER_EXEC, CLANG_ANALYZER_OTHER_FLAGS
Disclaimer: some of those build settings are undocumented (afaik). Use at your own risk.
(Taken from [cfe-dev] Compile/refactor iOS Xcode projects)
For me it was enough to define the following User-Defined Settings in Build Settings of Xcode projects:
CC=my-c-compiler
CXX=my-cxx-compiler
LIBTOOL=my-linker-for-static-libraries
If you use CMake, the way to inject your compiler automatically is to use
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CC "${YOUR_CC}")
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CXX "${YOUR_CXX}")
Couple of years ago I've written an article that addresses exactly the problem you describe: Creating and using Clang plugin with Xcode
To enable custom clang you need to actually patch internals of Xcode.app itself, it is technically doable but:
it will break when you update Xcode
it will work correctly on your machine
the version of a plugin and your compiler should match, i.e.
they should be compiled using the same tree
So in general it doesn't really scale, so be careful :)
There's a somewhat obscure feature of Xcode where it supports "alternative toolchains". For example, Swift.org provides installable toolchains for Swift built from current sources.
Unfortunately, while Apple's documentation describes how to install and use such alternative toolchains, it doesn't describe how to create them. There are scripts in the Swift source base which build a toolchain and you can look at them to figure out how it's done. They are in https://github.com/apple/swift/tree/master/utils. Start at build-toolchain, which calls build-script and go from there.
Method 1: Change the User Defined settings
Under the project or target Build Settings add the User Defined settings for
CC=/path/to/cc
CXX=/path/to/c++
This is useful if you have a single compiler or linker you want to call, or if you want to call out to a trampoline that decides what to call on the fly.
Method 2: Create a complete custom toolchain via plugin
Using Clang LLVM 1.0.xcplugin as a template (found in the Xcode.app plugins folder), you can modify the plist to point at your own alternative compiler and linker.
This OLLVM on iOS tutorial walks through it.
From project setting go to build setting with target selected. then select All beside the Basic from the top bar. then under build option you can see the compiler option.
Refer below screenshot,
Update :
I think you should refer Using C and C++ in an iOS App with Objective-C++ and this tutorial.
There seem to a variety of questions like this one without any clear solution that is true for Xcode 7 (or even other versions of Xcode).
I have a version of GCC that I'd like Xcode to use when it compiles. It is not the standard GCC but customized for a different platform. I can specify and use this compiler fine in Eclipse, but would rather use Xcode. The Build Options only list LLVM and nothing else. When I try to add via "other" in that section, all I get is this empty popup:
What goes in this box? I would think that it should be no big deal for Xcode to simply use a GCC that I have available at a specific path on my system, but this appears to be quite complex.
Update: Apparently there is a supported mechanism for installing externally-provided tool chains in Xcode that I wasn't aware of. For example, one can download packages from swift.org that install alternative tool chain packages into /Library/Developer/Toolchains or ~/Library/Developer/Toolchains. Once one of those is installed, Xcode has a GUI option to switch the active tool chain.
There was a recent change to the Swift sources to include a script for building one's own custom tool chain from them.
If you view the Quick Help for that build setting (View > Utilities > Show Quick Help Inspector) or configure the build settings view to show setting names instead of titles (Editor > Show Setting Names), you'll see that that setting is GCC_VERSION.
If you look that up in the Build Settings Reference, you find:
GCC_VERSION
Description:
Numeric identifier. Identifies the GCC version to be used to compile
the target’s source files. When the target’s “System C rule” is set to
GCC System Version (instead of a specific version number), this build
setting is not available in Run Script build phases.
Values:
2.95.2
3.1
3.3
4.0
Default value:
GCC system version.
Specified in:
Project Info > Rules > “System C rule.”
Target Info > Rules > “System C rule.”
Affects:
GCC_VERSION_IDENTIFIER.
That's actually a bit out of date. It says it's specified by fiddling with a build rule (not setting) called the "System C rule". You used to change the version there but now there's a direct build setting for it.
Anyway, this probably doesn't help you do what you want to do. I doubt there's any value you could put in there that would do something useful, let alone use a third-party compiler.
However, the explanation does have a hint. It mentions the System C build rule. You could modify the build rules on the Build Rules tab of the target configuration screen. You can find the System C rule and press the button to copy it to your target, which will let you specify a custom script to process C files (including Objective-C and C++).
Implementing such a script is non-trivial. The inputs, expected outputs, and required behavior of the script are not well documented. There are various environment variables available for the use of such a script. Some are the build settings. You'll need to translate the relevant settings into compiler options. For example, translate the CLANG_WARN_BOOL_CONVERSION setting into the corresponding -Wbool-conversion option.
Some of the other environment variables indicate which file you should operate on, such as INPUT_FILE_PATH, INPUT_FILE_NAME, etc.
You need to tell Xcode what file(s) your rule outputs. These can be based on the input environment variables/settings, such as $(OBJECT_FILE_DIR)-$(CURRENT_VARIANT)/$(CURRENT_ARCH)/$(INPUT_FILE_BASE).o.
In general, this is just not something that Xcode makes easy.
Someone wrote a plugin that will allow you to use gcc from Xcode.
http://hamelot.io/programming/add-gcc-compiler-to-xcode-6/
If you have a custom gcc then you would need to change the paths around etc but the plugin should work.
I have a XCode(in Swift) project with multi targets. Each target has its own macro that program can know which target is being run.
For example,
FreeVersion target has a macro "FREE"
PaidVersion target has a macro "PAID"
I would like to make test code with XCTest but it seems like XCTest source cannot be related to a specific target.
What is the best practice for using XCTest in such a situation?
Actually, the test bundle is associated with a specific app target through the TEST_HOST build setting. So I think it should be possible to set up two test targets. Each can have its own prefix header (pch) to set the macro you need, and specify their TEST_HOST.
If you duplicate your current test target, be sure to check the new build settings carefully. I've found that Xcode likes to change some settings in the duplicate but not others.
In XCode 4.5, my preprocessor macro gets ignored when defined at target level, but honored if defined at project level. It's a simple symbol definition (RESTKIT_GENERATE_SEED_DB) to be used in #ifdef. Using "levels" display, XCode shows my symbol in the resolved section. Also, I have double-checked that my current scheme is running the Debug config where macro is defined.
This was a newbie mistake. The setup was that I had two targets, one with the macro defined and one without. The reason the macro was not picked up at target level was that I never ran that target. I thought that you ran it by selecting the target in the target list under TARGETS. I realize now that in order to run a target you must select it the scheme menu next to where you select the device target.
ARC stands for automatic reference counting.
I just upgraded my project to use ARC. Not all though. Just some.
How do I know?
To see the default you have to check the target properties (Your Target -> Build Settings -> Apple LLVM Compiler - Language -> Objective-C Automatic Reference Counting)
Then you can change the setting for every .m file: Your Target -> Build Phases -> Compile sources -> you have a list of -m files and for each file a field "Compiler Flags". To disable arc for that file pass as flag -fno-objc-arc. To enable (if you have arc turned off by default) -fobjc-arc
EDIT: i added an image of a project..
Look for the -fno-objc-arc flag on the files in your target's Compile Sources build phase, as shown in this answer.
if at the source level, this question answers it: How do I know whether the compiler has ARC support enabled?
if at the build settings level, see -fobjc-arc or its inverse -fno-objc-arc. if not defined, defaults to off.