Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 27
Текст из файла (страница 27)
This generates verbose output so you can see the developmentsystem tool commands as they are invoked.build target specifies a build target name that indicates the toolsetoptions and determines if you are building for the emulator or the phone.Section 5.4 describes build targets in more detail and provides a list ofthem.build type should be udeb for builds suitable for source-leveldebugging. build type of urel indicates a release build with nosymbols.5.3.2 The MMP FileAn MMP file (sometimes referred to as the project definition file) is a textfile used to define a build in a platform-independent way. Each statementin the file begins with a keyword. Statements can span multiple lines byusing a forward slash at the end of the line to be continued.The following shows the project definition file for an example programbuilt with the S60 3rd Edition SDK.TARGETTARGETTYPEUIDSOURCEPATHSOURCESOURCESOURCESOURCESOURCESOURCEPATHSimpleEx.exeexe0x100039CE 0xE000027F..\srcSimpleEx.cppSimpleEx_app.cppSimpleEx_view.cppSimpleEx_ui.cppSimpleEx_doc.cpp..\groupBASIC BUILD FLOWSTART RESOURCETARGETPATHENDSTART RESOURCEHEADERTARGETPATHENDSYSTEMINCLUDEUSERINCLUDELIBRARYLIBRARYCAPABILITYSECUREID129SimpleEx_reg.rss\private\10003a3f\appsSimpleEx.rss\resource\apps\epoc32\include..\includeeuser.lib apparc.lib cone.lib eikcore.libavkon.lib gdi.libNone0xE000027FThis section describes some of the main MMP file statements.
Youshould consult the Tools and Utilities guide in Symbian OS Library thatcomes with the SDK documentation for a complete list and descriptionof MMP statements.•TARGET program name specifies your program’s executable filename, for example:TARGET myprocess.exeTARGET myfuncs.dll• TARGETTYPE type specifies the type of executable that is to becreated. The two main target types are:–exe – Process executable, includes GUI applications (in preSymbian v9, GUI applications should be of type app).–dll – Dynamic Link Library (DLL), that is, a shared library executable.• UID uid2 uid3 specifies the second and third UIDs for your component.
Refer to section 5.5 for information on UIDs in Symbian OS, forexample:UID 0x100039CE 0xE000027Findicates a GUI application (0x100039CE) with a unique UID of0xE000027F.• SOURCEPATH path specifies the directories to search through to findthe source files listed in the SOURCE statements.path is either relative to the MMP file location or can be a fullyqualified path.Only one source path is in effect at a time, and it is active untilchanged by the next SOURCEPATH statement.•SOURCE source file 1 source file 2 .
. . specifies the sourcefiles that make up your project. Multiple statements can be used andmore than one file can be included in each statement.130SYMBIAN OS BUILD ENVIRONMENTSOURCEPATH and SOURCE are used together to specify your project’ssource files, as in the following example:SOURCEPATHSOURCESOURCESOURCEPATHSOURCE..\myclassclassx.cpp classy.cppclassz.cpp..\myfuncsfunc1.cpp func2.cppThese statements specify that the build includes classx.cpp,classy.cpp, and classz.cpp from the ..\myclass directory, andfunc1.cpp and func2.cpp from the ..\myfuncs directory.• START RESOURCE resource file indicates the start of a sectionthat describes building resource file resource file.
The resourcesection is ended with the keyword END. The location of the resourcefile is determined by the last SOURCEPATH statement before theresource section. The TARGETPATH target directory line withina resource section indicates where in the device the compiled resourcefile (.rsc file) should be placed on the device.TARGETPATH resource\apps should be used for the applicationresources.TARGETPATH \private\10003a3f\apps should be used for theapplication registration resource files. The build will compile theseresources once for every language that appears in the LANG statement.The HEADER keyword within a resource block is optional and tells thebuild tools to generate an include file so that the application code canreference the resources in the file.
Resource files, including resourceregistration files and language translations, will be discussed furtherin Chapter 12.•SYSTEMINCLUDE include path 1 include path 2 . . . containsa list of paths that will be searched for system include files (e.g.,#include <estlib.h>).•USERINCLUDE include path 1 include path 2 . . . contains alist of paths that will be searched for non-system include files (e.g.,#include "myinc.h").•MACRO macro-1 macro-2 . . . defines each macro in the list to havethe value ‘1’ (as in the compiler -D option). For example, if a projecthas the following line in its MMP:MACRO TEST_FLAGBUILD TARGETS131and a source file in that project implements:#ifdef TEST_FLAGthe #ifdef evaluates to true.•CAPABILITY cap 1 cap 2 .
. . specifies the platform security capabilities (i.e., units of trust) needed by the application. These capabilitiesare discussed in more detail in Chapter 7. CAPABILITY None meansthat the application requires no capabilities, and this is the default ifthe CAPABILITY line is not put in the MMP file.•SECUREID sid indicates the application’s Secure Identifier (SID),which is used to construct the name of the secure data-caged directoryassigned to the application as \private\<sid>. This directory isprivate to the application and cannot be accessed by others unless theyhave sufficient permission to do so – for example, by possessing highlyprivileged capabilities (very few applications have this permission).
Ifthe SECUREID line is not in the MMP file, then SID defaults to yourapplication’s UID3 (this default is recommended). SIDs are part ofthe platform security architecture, which is covered in more detail inChapter 7.• LIBRARY lib 1 lib 2 specifies what libraries to link to. Theseare the statically linked import libraries your application uses to callshared library (DLL) code at runtime.
You always specify the libraryfiles as .lib files here, even though the actual library files may end in.dso, depending on your build target (see the next section for moreinformation).•EPOCSTACKSIZE stack size changes the application’s stack sizefrom its default of 0x2000 for Symbian OS v9.1 (0x5000 in OSversions before v9.1) to the value specified in stack size. Thisis an optional keyword and not used in the examples of this bookbecause the stack size should be kept to a minimum and the defaultis sufficient for our use.5.4 Build TargetsAs mentioned in section 5.3.1, build targets specify the toolset and modefor a build and if the build is for the emulator or the device.
Specifyingthe build target in the abld command causes the application to be builtusing it. Note that you may also need to put that build target in yourbld.inf file under the PRJ PLATFORMS keyword if that build targetis not one of the defaults supported by the SDK (WINSCW and GCCE aretypically the default supported platforms).132SYMBIAN OS BUILD ENVIRONMENTThe build targets supported by Symbian OS v9 SDKs are listed in thetable below:Build TargetTypeCompilerWINSCWEmulatorNokia x86 compilerGCCENativeGCCARMV5NativeRVCTARMV5 ABIV2NativeRVCT (ABI v2 mode)ARMV6NativeRVCTWhen you specify a build target in your build command, the buildgenerates and executes a makefile that invokes the development toolsneeded to produce the appropriate binary output. The executables arethen placed in the \epoc\release directory under the appropriate buildtarget’s name, as described previously.5.4.1Emulator Build TargetsOn Symbian OS v9 SDKs, WINSCW is the usual build target used tocompile your Symbian OS application for the Windows emulator.
Asmentioned before, WINSCW uses the Nokia x86 compiler (previouslyknown as the Metrowerks compiler), which is the compiler used byCarbide.c++ as well as Carbide.vs.The emulator targets generate x86-based Windows binaries; however,you need to use the build target that corresponds to the Windows toolsetyou have on your PC. This ensures that your Windows development toolsare invoked when building. In addition to invoking the correct tools,each emulator build target has its own emulator executable. It’s requiredthat the emulator, system code, and user programs are compiled with thesame Windows compiler – this is needed so that they can link togethercorrectly.The emulator build target support varies with the SDK.5.4.2Native Build TargetsNative build targets specify builds for the smartphone device, whichmeans building for the ARM processor.
For Symbian OS v9, GCCE is thebuild target you will most likely use. GCCE uses the GCC CSL ARM toolchain that is provided free of charge along with the Symbian OS SDK(starting at Symbian OS v9).BUILD TARGETS133You can also build for the smartphone using the ARMV5, ARMV5ABIV2, or ARMV6 build targets. These build targets use the ARM RealViewcompilation tools (RVCT) development tool chain. The ARM RVCT compiler produces code that is more optimized and thus runs faster than GCC.These build targets, however, are intended for device manufacturer andsystem-level (e.g., device drivers) development. The main reason is that,unlike GCC, the ARM RVCT compiler is not included in the Symbian OSSDKs, and must be purchased separately – for a fairly hefty price.Except for some mentions in the next couple of sections, this book willnot discuss the ARMV5, ARMV5 ABIV2, or ARMV6 build targets and we’lluse GCCE exclusively for native builds.Application binary interface (ABI)ARM tools support a standard known as an application binary interface(ABI) to allow different ARM tools to interoperate together in a consistentmanner (for smartphones, they are also known as EABI, for embeddedABI).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
