How can I force Xcode to use a custom compiler? - xcode

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.

Related

How to enter custom GCC compiler option in Build Options

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.

How to conditionally compile version-specific Swift (1.2 vs 2.0) code in the same source file?

I have a Swift demo project that comes bundled with my framework. I want to ensure that the Swift code in the demo compiles successfully with both Xcode 6 (Swift 1.2) and Xcode 7 (Swift 2.0) without user intervention.
Since there's only marginal preprocessor support in Swift, how can I determine at compile-time which version of Swift or Xcode is being used to compile the code?
Now, here's the important detail:
It has to work automatically!
Open the project in Xcode 6 -> compiles
the Swift 1.2 code.
Open the project in Xcode 7 -> compiles the Swift
2.0 code.
No build settings or other means that require the user to specify, one way or another, which Swift/Xcode version she is using.
I keep thinking: this is such a trivial task, how could that not be possible with Swift?
As a framework developer this is driving me nuts since a successful compile of a Swift project now entirely depends upon the user's version of Xcode, and I can't ask them all to "update to Xcode 6.4" and at a later point having to ask them all over again to "update to Xcode 7.1". This is insane!
The alternative would of course be to have separate demo projects, managing different code bases, one for each version of Swift. And hoping the user will know what project will work with her version of Xcode. Not a real alternative.
The other alternative, to simply not use any of Swift 2.0's enhancement, is unfortunately not possible either. There is syntax, classes and methods that won't work in one or the other Swift version, if only due to the compiler being more picky in newer Xcode versions.
You can accomplish this using some of Xcode's advanced build settings, in particular:
XCODE_VERSION_MAJOR: Which encodes the Xcode major version as a string like "0700".
EXCLUDED_SOURCE_FILE_NAMES: A "fnmatch"-style pattern of source files to exclude by default.
INCLUDED_SOURCE_FILE_NAMES: A "fnmatch"-style pattern of source files to include.
I would not generally recommend doing this, as it will make your project hard to understand for most Xcode users, but if you absolutely want to make it work you can use this technique.
The way you accomplish it is as follows:
For any source files which need to be versioned, name them something like "Thing-Versioned-0600.swift" and "Thing-Versioned-0700.swift". Make sure both files are in the sources build phase.
Use the excluded mechanism to prevent any versioned files from being compiled by default, by adding a project-level build setting: EXCLUDED_SOURCE_FILE_NAMES = *-Versioned-*.swift.
Use the included mechanism to only add back in files that match the current Xcode major version, by adding another project-level build setting: INCLUDED_SOURCE_FILE_NAMES = *-Versioned-$(XCODE_VERSION_MAJOR).swift.
Having 2 versions of the code inside your project won't work since the code would not compile. There is no compiler directive for conditional compiling based on a version.
There is one workaround that could work (did not test it)
First create 3 files named version_current.swift, version_1_2.swift and version_2.swift. Make sure that only version_current.swift is part of your build target.
Then create a new build script phase and place it right above the 'compile sources' phase. In that script you will copy over the content of either the 1_2 or the 2 version over the current.
My scripting knowledge is not so good, so I can't give you much help doing this. You can get the version with code like:
$ xcrun swift -version
And then just execute a copy statement.
But then this will only work for the default Xcode version on your system. When you want to use a different version, you also have to change the default version.

Xcode compiler plugins & native build settings for platforms

I'm coming up against a problem in the creation of an Xcode compiler plugin that appears to be the result of a problem in the way compile lines are generated by Xcode and how some of these options are overridden by the platform SDK.
Upon creating a custom compiler plugin that functions perfectly when building applications for MacOSX. I noticed a problem when building applications for iPhoneOS. The SDK continually complains about an invalid value in the min-iphoneos-version variable, the reason being that this isn't set on the compile command-line. Looking at the iPhoneOS platform SDK for Xcode5 you notice that the setting is defined in the 'Native Build System.xcspec' file (Applications/Xcode.app/Contents/Developer/Platforms/iPhone*.platform/Developer/Library/Xcode/Specifications/). Essentially, from what I can gather, this file is consulted and the -mmin-macosx-version flag is overwritten with this command-line option which results in a valid build for Apple compilers. However, create your own compiler plugin and problem ensue since your new compiler will not be matched by any of the 'Compiler' definitions in the 'Native Build System.xcspec' file.
I can only think of a couple of solutions to this,
rewrite/patch the 'Native Build System.xcspec' file upon installation, resulting in an horrendous solution requiring making unsupportable patches to Apple's build system.
another technique that allows a custom compiler plugin to define options specific for a platform SDK via some matching technique,
if a new .xcspec file is added to a Plugin in the PrivatePlugIns directory as a Resource, do all of these files get parsed upon build-time? if so then it may be possible to add these settings to a file such as,
Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/PrivatePlugIns/iPhoneSimulator Build System Support.xcplugin/Contents/Resources/MyPlugin.xcspec
Has anyone else come up against this 'road-block' (ahem, design problem)?

How to integrate a custom clang into Xcode 5?

What is the best way to integrate a custom clang toolchain
into Xcode5?
I tried to replace the standard clang with mine and got many errors about missing header files.
You can't. Apple patches Clang before it ships it with XCode, to accept certain options that the IDE uses when calling Clang.
You can always use a non-XCode project build system and build outside the IDE. Or use a different IDE.
If you still want to try, it sounds like you didn't configure Clang correctly to find all your system's header files. You need to configure Clang to use the ones you want using
--with-c-include-dirs
--with-cxx-include-dirs
or something like this. Inspect LLVM's configure --help output on the real options and what they should be, I can't seem to find any decent documentation currently.

Working with openFrameworks in Qt-Creator

How can I use OF within Qt Creator environment?
I fact , how should I build the lib and add it in my .pro file and all.
I have successfully done a porting of open frameworks project in creator loading plain Makefile projects.
You can add the includes directory in the file projectName.includes to have auto-completition and file navigation (just do it with a find shell command against OF_PATH/libs) and it is very handy.
Moreover config.make and addons.make let you use the builtin project-creation tools and workflow provided by the official community project management system, and also add external binary/libraries/shared components with the standard gcc command (-I for example).
In this way you can use QtCreator and do not care about .pro/.pri files and use the makefile projects (I have tested it both on linux and mac/osx) and I think there will be no problem also with arch compiling.
Also no problem with C++11 (even if I haven't tested all new features of the language).
See this post in the official forum.
Check out this github repository: https://github.com/procedural/ofqmake There is a qmake project file (.pro) if you want to build openFrameworks using qtcreator as well as a qmake include file (.pri) if you want to use oF in your own projects.
This is exactly what you want to do. Get the openFrameworks.pri file and include it in your .pro file by adding include(openFrameworks.pri).
Qt itself provide an open-framework called Qt-Complex. Go through it and you can find how to add a framework to your project there.
To update this topic again, since OF9.0, QT Creator is now officially supported (and even the default recommended IDE!).
See this setup Guide: http://openframeworks.cc/setup/qtcreator/

Resources