<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept xml:lang="en" id="GUID-AE3BE603-21ED-5DEA-B1E9-0F1ADBED06D0"><title>Build-time variants</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>It is a common requirement to be able to build more than one variant of a program from a single set of source code. For example, you might have evaluation and full variants of a program that are identical in most respects, but which differ in a few features; or might want to build a program for more than one platform, with some features being present on platform but not on the other. </p> <p>A traditional way to handle this requirement is to use the pre-preprocessor to conditionally include sections of code depending on whether a macro is set or not. For example: </p> <codeblock id="GUID-28BD78C2-15CB-52F8-8725-E9A7692AA8DF" xml:space="preserve">#ifdef MY_FLAG

    // code that is compiled if MY_FLAG exists

#else

 // code that is compiled if MY_FLAG doesn't exists

#endif</codeblock> <p>Note that this is not always the best approach, as it can make code difficult to read and maintain. Alternative approaches to consider can include: </p> <ul><li id="GUID-2556ADBE-D6F5-53A2-A00D-8ACE7C26ACC5"><p>run-time detection: e.g. unless a file with a registration key is present, restrict the available options to those for the evaluation version </p> </li> <li id="GUID-B632DA8E-2AAF-548B-B527-EF31B5A1C9CC"><p>plug-in architectures: e.g. if you want to write a program that runs on platforms that may or may not have Bluetooth, then isolate all Bluetooth code in a plug-in that can be dynamically loaded at run-time if appropriate </p> </li> </ul> <p>However, if conditional compilation is needed, you can configure the build tools to read a file that defines the macros to use. To do this: </p> <ul><li id="GUID-EBDB484D-4C1C-5384-BB3D-BEB781DB0983"><p>create a file that defines the macros as <filepath>#define</filepath> statements. By Symbian platform convention, such files should have an <filepath>.hrh</filepath> extension. The file can be anywhere on the same drive as the <filepath>epoc32\</filepath> directory. </p> </li> <li id="GUID-5AD4F8EC-0BF1-56E3-8EAB-46C0DF929789"><p>create a sub-directory of <filepath>epoc32\tools\</filepath> called <filepath>variant\</filepath>, and create in it a text file called <filepath>variant.cfg</filepath>. The file must specify the full path to the <filepath>.hrh</filepath> macro file. Perl-type comments (marked with #) are also allowed. </p> </li> </ul> <p>When you use <filepath>bldmake</filepath> or <filepath>abld</filepath> on the command line, the build tools look for the <filepath>variant.cfg</filepath> file, and set any macros defined in the specified file. By adding/removing/changing the <filepath>variant.cfg</filepath> file in your build environment, you can alter which macros are set, and so how your project is built. </p> <p>For IDE builds, the macros are set when the IDE project file is created, and not changed unless you recreate the IDE project file. </p> <p>Note that you can use the macros in bld.inf and .mmp files as well as in C++ files: this allows you to conditionally specify projects, source files, etc. </p> </conbody></concept>