Moodstocks – Free image recognition API and SDK for mobile apps – iOS and Android software

As you probably know the Moodstocks SDK core library is written in C and thus is cross-compiled for the target platforms – iOS and Android so far.

Until the latest release (v3.4) we used the GCC 4.2 front-end compiler for the iOS build. We then decided to switch to Clang for several reasons and benefits I will talk about in this post.

The LLVM Project

Top

Clang is a C/C++/Objective-C compiler front-end that is part of the LLVM Project. It’s a very handy compiler to work with because it’s fast – expect faster compile times, and provides a great user experience – via so-called “expressive” error diagnostics.

On my side I was lucky enough to attend Chris Lattner‘s talk at FOSDEM 2011 - Chris is the creator of the LLVM project, and if you want to get a recap in terms of features and benchmarks around LLVM you should definitely browse his slides which are available online.

Xcode default compiler

Apple, which is one of the main company involved within the LLVM project, has now fully switched on it for iOS development: if you grab the latest version of Xcode (4.3.3 at the time of writing) the default and official compiler for iOS is now LLVM. Indeed Apple started migrating from GCC to LLVM as of Xcode 4.1.

That is the main reason why we decided to switch too. But not the only one (see below).

Switching to Clang

Top

Dev tools

When it comes to cross-compiling a C library for the iOS platform, you need to use the proper tools – compiler, linker, archiver, etc, right from the iOS SDK toolchain.

For that purpose Xcode comes with a handy command-line tool called xcrun. With it you can easily obtain e.g. the path of the right version of Clang or even directly execute a command:

# Find the right Clang path for iOS cross-compilation xcrun -sdk iphoneos -find clang # Pick the right tool and run the command (here list #define-s) xcrun -sdk iphoneos clang -E -dM - < /dev/null

With it you can definitely simplify your Makefile or build scripts. For example xcrun is used by the VLC project for its iOS port:

# From git://git.videolan.org/vlc.git: # extras # â Static analyzer With Clang comes another incredibly powerful piece of software to help you track potential bugs at dev time: the Clang Static Analyzer. What’s really cool about it is that it’s non intrusive – in a way it simply wraps around your build commands, it can be used right from the command-line (w/o IDE) with the standalone mode and it provides shiny HTML formatted results. Here’s how to use it e.g. to analyze the hiredis project – the C client library for Redis:

If the static analyzer founds errors it automatically display a report in your web browser:

The check boxes are used to filter the reports entries below. In addition, for each error you can click on View Report which opens in a new tab the related code section including a detailed explanation of the error, in a storytelling fashion:

Here the Clang Static Analyzer points out that if the if condition is true, then the function will exit prematurely without releasing the memory allocated for tokens, hence the memory leak.

Obtaining such powerful and easy-to-navigate reports so easily is priceless!

Controlling diagnostics via pragmas

Our policy is to compile our code with -Wall -Werror. That said we have some libraries as dependencies, such as msgpack. And these libraries may contain several kinds of warnings – this was the case with the msgpack version we use that issued some unused-function warnings.

To avoid breaking our build our decision was to patch our msgpack version taking benefit of Clang diagnostic control via pragmas. To sum up, Clang offers the ability to bracket some code section so that to ignore some warnings. It works with a push / pop mechanism, and it’s both handy and simple to use!

/** * This is an extract from msgpack code. * * By default Clang returns warnings such as: * * deps/build-ios/include/msgpack/vrefbuffer.h:133:21: error: unused function * 'msgpack_vrefbuffer_vec' [-Werror,-Wunused-function] * const struct iovec* msgpack_vrefbuffer_vec(const msgpack_vrefbuffer* vref) * * You can turn them off by bracketing the code as follow: */ #ifndef MSGPACK_VREFBUFFER_H__ #define MSGPACK_VREFBUFFER_H__ #if __clang__ #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wunused-function" #endif /* ... msgpack code here: any unused function warning is now ignored ...*/ #if __clang__ #pragma clang diagnostic pop #endif #endif /* msgpack/vrefbuffer.h */

Note: since the push / pop is placed within a header file – which is included into your project, do not forget to pop otherwise the warning will continue to be ignored for all subsequent compiled code!

Performance

At last, and as stated above, switching to Clang has also driven several performance boosts:

• faster compile times: this is really appreciated at development time when you iterate frequently on your code – remember this My code’s compiling xkcd?
• faster execution times.

Switching to Clang compiler

The LLVM Project

Xcode default compiler

Switching to Clang

Dev tools

Controlling diagnostics via pragmas

Performance

About cedric

Leave a comment

Categories

Recent Comments

Tags

Blog

Developers

Community