I have a third party project in my Xcode workspace (it's a dependency for my main project) and I want Xcode to ignore all build warnings from that third party project.
Preferably I'd like to ignore all build warnings for the Vendor/* group in my project since that's where I put all my third party code.
Possible?
Yes, it's possible, but only if you compile the third-party files in a separate target. This way, you can set different compiler flags.
Let's say your main target is an application. You defined your build settings, as well as the compiler warning flags.
Now you want to use some third-party sources. You import them into your project, but they generate warning. You could of course change your main target's settings, but I'm pretty sure you want to keep your own settings.
Simply create an additional target in your project, which is a static library.
Removes the third-party files from your main target, and add them to the library.
In your main target's build phases, link your application with the static library.
This way, you'll be able to use the third-party code in your application, while having different compiler settings for third-party code.
It is possible on a per file basis, see the blog entry at http://blog.bluelightninglabs.com/2011/12/suppressing-xcode-warnings-on-a-per-file-basis/
To summarize: Use the compiler flags on the “Build phases” tab.
Go to Build Phases > Compile Sources. Optionally filter the list. Select the ones you want to exclude and then double click in the blank area under the Compiler Flags column. Add -w and hit return:
if you are worried only about warning via inclusion, then you can wrap your include statements in this:
#pragma clang diagnostic push
// in reality, you will likely need to disable *more* than Wmultichar
#pragma clang diagnostic ignored "-Wmultichar"
#include <TheirLibrary/include.h>
#pragma clang diagnostic pop
if you also want to disable the build warnings it generates, then you can use -w or GCC_WARN_INHIBIT_ALL_WARNINGS = YES for the third party target which you link to or bundle.
ideally, you will file reports with the vendor if it is closed. if it is open, then maybe you should just patch it yourself.
Related
I am building an .xcframework which contains an iphonesimulator and iphoneos frameworks. There is some Swift code, and some C++ code, which is linked into a shared object (Mach-O 64-bit dynamically linked shared library arm64). I build my C++ with -fvisibility=hidden, and only the symbols that I explicitly mark, are exported. But, when I run nm -gC, I see all kinds of symbols that are still there – and they are visible even in the iOS app that is built using this framework. For example, I have an inner class Secret (it is only used in one cpp file). And nm -gC shows me (and all hackers out there)
00010292 t Secret::getString() const
Is there a way to hide this and other sensitive information?
And, on the other hand, how can I keep the auto-generated _AlexSDKVersionNumber exported?
You should configure your project settings correctly for Stripping to hide internal names.
Go to Your target > Build Settings > Deployment:
Set Deployment Postprocessing to YES to enable Stripping.
Set Strip Style to Non-Global Symbols.
Now nm should provide global (external) symbols only for your binary.
As for keeping the auto-generated _AlexSDKVersionNumber exported, I came up with a not-so-dirty hack:
add a header file to my project, call it AlexSDK_vers.h:
extern __attribute__ ((visibility("default"))) const double AlexSDKVersionNumber;
in Build Settings, add OTHER_CFLAGS=-include\${PWD}/AlexSDK/AlexSDK_vers.h
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 compile my Xcode projects with very high warnings settings. Sometimes, I have to use third-party frameworks that are distributed as source (rather than as a framework). These frameworks often throw a lot of warnings.
Is there a way to turn off warnings for these folders? I want the stricter level for my own code, but don't care if third-party code violates my warnings level.
Basically, I don't want to see 67 warnings every time I build.
You're looking for this:
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
Flags can be found here: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Warning-Options.html
Just replace the -W... with whatever you want to ignore.
I have a Xcode project for library arith.
I could build it with debug configuration, and I need to debug it. How can I do that?
The ideal method would be to set up a test code to build an execution in a project file, and then set a breakpoint in a source code in arith library.
However, it seems that Xcode arith project doesn't allow to add another use_arith project that uses the arith library.
What method people use to debug a dynamic library in Xcode?
ADDED
I googled and found some ways to debug dll. Attaching to a running process can be one way of debugging dynamic library. And, for iPhone/iPad programming dynamic library is not allowed, so static library is used.
Attaching to a Running Process - http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Attaching-to-a-Running-Process.html
Debugging a library with Xcode - Debugging a library with Xcode
Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References - http://www.clintharris.net/2009/iphone-app-shared-libraries/
I could find a way to debug dynamic library in Xcode.
Build
Make a library, I'll call this arith library. Debug build to make libarith.dylib.
Make a project to use the library, I'll call this usearith.
For userarith, Project->Add To Project, and add the arith library.
Open Project info, and open the Build tab.
Go to Search Paths/Library Search Paths, drag and drop the arith library. You should remove the library name as you need only specify the path. Specify the header directory with 'Header Search Paths'.
Go to Linking, set Other Linker Flags, add -larith
Running
Now, you should be able to link the execution binary to the library.
For running, you need to copy the dynamic library to the directory where the execution binary is located.
Debugging
You need to set the breakpoints both arith/usearith.
You can run debugger in arith and use the step into to debug the code in a arith project.
I faced the same problem and no one of the previous answer worked for my case so I share my solution (for Xcode):
If you need to debug a c/c++ dylib which is loaded by an external (executable) program:
First be sure that your dylib is build with the same architecture as your external program.
Then Go to --> Product —>Scheme—>Edit scheme
Got to Tab Run(Debug) and check "Debug Executable" , then select into the dropdown button your external program as executable. Then check "Launch Automatically"
Additionally if you program needs extra argument you can add it into the
"Arguments" tab.
Finally you set some breakpoints to your c source file and finally click run.