The numerous Symbian SDKs share a
special build system developed by
Symbian for the use specifically with
the SDK. Some of the Symbian IDEs
build on top of it, in order to provide
integration with the SDK.
C++ BuilderX in particular integrates with the default
build system very well. Although there exist alternative ways
to build things for Symbian (as the
Rudolf König SDK on Unix using plain
GNU Makefile), the Symbian build
system is somewhat standard in the
Symbian C++ world. So I believe that it must be known by every Symbian C++
programmer and I will teach you how
to use and develop applications with it. A Symbian application source usually
stores, in a directory named 'group', the
file 'bld.inf' and one or more files with
extension '.mmp'. You define the build
for your Symbian application by writing b l d . i n f and at least one p r o j e c t . mm p . Then you process these files with a tool named
'bldmake' and will obtain a batch file
('ABLD.BAT') and some makefiles that
will build the application for you. This tool exists mainly because a
Symbian application is usually built for
many platforms: the emulator, using a
Microsoft X86 compiler, as well as the
real device using a gcc-derived ARM
compiler. The b l d m a k e saves you from writing specially crafted makefiles
for these compilers and make utilities;
also it allows for building many targets
with just a single command. In fact, 'bldmake' is quite easy to use IF
you accept the way it works. If you
don't, you will suffer endless
nightmares in order to build things the
way you want. Another drawback is
the fact that it is somewhat slow, so you have to compile, build and start the
emulator, and always wait some time
in the middle of the process. Let's explain how it works with an
example. Open a command line prompt,
and after changing to the directory
containing the b l d . i n f , t y p e : > b l d m a k e b l d f i l e s Of course, you must have the PATH set
correctly for the installation of the SDK
you are using. This command will look
for the b l d . i n f , process it and the related * . mm p , then generate a BATCH file named A B L D . B A T . Now you have all you need to build your
applications. Simply type: > a b l d b u i l d This will build your application in all the
available flavors. Well, in fact you are
building eight (!) different binaries. Note
that the target files are stored in a very
deep directory structure, and you are
building both in debug and release versions for WINS (windows), ARM4
(plain arm), ARMI (speed optimized
arm), THUMB (size optimized ARM)! But
you can choose to build for only one
target, and since it take less time, you
usually build ONLY for one version of one target. For example, to build for the
emulator only in the debug version, or
for the device, optimized for size, in
release version, you type: > a b l d b u i l d w i n s u d e b > a b l d b u i n d t h u m b u r e l Building for Windows is enough to start
the emulator and run the application in
the emulated environment. Application
files are compiled and placed straight
where the emulator can run it: no need
to copy them in the right location. But for real devices, you have to pack
everything in a . s i s file for installation, send it to the phone and
install the application. You are required
to write a . p k g file to describe the installer, and then create it with:
> m a k e s i s f i l e . p k g
References:
BldMake
ABLD
Submenu
2.1 Binary Files
2.2 Source Files
2.3 The build process
2.4 The .mmp
2.5 The AIF
2.6 Create an installer
2.1 Binary Files
A Symbian GUI Application (for
example, Hello), when compiled and
installed in the device, is comprised (at
least) of the following three files: Hello.app Hello.rsc Hello.aif H e l l o . a p p is the real application: it is essentially a DLL
(dynamic link library) containing the
logic of the application. H e l l o . r s c is the compiled resource file, containing the description
of the GUI of your application. The . a p p uses and references information taken from the . r s c file. The file
H e l l o . a i f is the Application Information File. The main
purpose of the . a i f file is to display an icon in the menu of the phone,
allowing the user to start the
application by clicking on the icon. It
contains the icon bitmap and some
runtime information about the
application.
Source Files When you look at the source for a C++
application for any Symbian SDK, you
will notice many source files. Some of
them can look strange to the eyes of a
programmer not accustomed to
Symbian. So let us look at each of them, explaining their meaning and purpose. First of all, files are usually placed in
many different directories: S r c : C++ source files I n c : C++ header files (includes) G r o u p : Building and packaging files A i f : Application information files, to create the icon We already reviewed and explained
files usually found in the G r o u p directory: . i n f and . mm p , used to compile applications with the Symbian
build system. In this directory you can
also find a . p k g file containing the instructions to create a package, i.e. an
installable file for the Symbian OS
characterized by the . s i s extension. In the I n c are usually placed some . h files, and in the S r c there are . c p p source files; of course they are ordinary C++ headers and source files. Symbian describes the GUI using
resource files, having extension . r s s . These files are placed both in G r o u p and A i f directories. These files must be compiled with r c o m p (the resource compiler), generating a
compiled resource file with extension . r s c . There is another header type, with . h r h extension. This header type is shared between . c p p and . r s s . It usually contains all the definitions
required use a resource from the C++
code. The resource files in turn may
include . r h files, where system header definitions are stored. Note that by compiling the . r s s you can generate some identifiers used by
the application. So after building the . r s s file, you can get a . r s g that is in turn included by a . c p p . Also, you can place localization strings
in a separated . l o c file (and related . l 0 1 , . l 0 2 and so on - the number identifies the locale), and
include them in the . r s s . We will examine localization in detail later. Lastly, you need to build an . a i f ; you use an . a i f s p e c or a specially crafted . r s s to create it. Also you require for the . a i f a multi-bitmap . m b m. This is in turn obtained by the utility b m c o n v starting from ordinary Windows . b m p files.
The build process Now we can examine the whole build
process of a Symbian application.
Symbian C++ programs are written, of
course, in C++. Your program is
comprised of many ordinary C++ files.
For a GUI application we usually need at least four of them: the application, the
model, the controller and the view. So
we have at least four C++ files, for eg: H e l l o A p p . c p p , H e l l o D o c u m e n t . c p p , H e l l o A p p U i . c p p and H e l l o V i e w . c p p . All the code could be stored in a single
file, but usually you place each class in a
couple of files. A file contains the
declaration of a class, and has extension . h , and another file stores the implementation of the class, with the
usual . c p p extension. So we will have also H e l l o A p p . h , H e l l o D o c u m e n t . h , H e l l o A p p U i . h and H e l l o V i e w . h . When you compile such files, you generate a . o binary from each . c p p . The . h files are used in compilation (they are
included in the .cpp files). At the end of
the process you link together the . o to obtain an executable; having the
extension . a p p for a GUI application (other extensions like . e x e are also possible). GUI applications also separate code and
resources. Resources are a Symbian-
specific special format that will be
compiled by the Symbian resource
compiler, the r c o m p utility. A resource file source form has the
extension . r s s , so we can also have H e l l o . r s s among the sources of our program. You can have more than one . r s s and place part of the resources in a
common file, included from many . r s s files. A resource inclusion file has usually extension . r h . When you compile a resource file, you get a binary . r s c that must be included in the deployment of your program. The . a p p will access the . r s c . Now here is an important case: some
declarations in the . r s s must be shared between the . r s s and the . c p p . And, to make things more complicated, the shared part can be
written by and/or generated from the
compiled . r s s . You place the hand- written part that must be included both
in a . c p p and a . r s s in a file with extension . h r h . Such a file usually contains only enums, since this is the
format that is understood both by the C
++ compiler and the resource compiler.
After compiling a resource, the resource
compiler generates some values that
must be further included in a source . c p p . The
generated file has an extension . r s g . Note that a . r s g file is a source file (ascii, not binary) but
it is generated, not hand-written.
2.4 The . mm p The build system for a C++ Symbian
application requires you to write a b l d . i n f file like this (check here for the complete syntax): P R J _ M M P F I L E S p r o j e c t . mm p Then you write the p r o j e c t . mm p (also go go here for the syntax) like this: T A R G E T H e l l o W o r l d . a p p T A R G E T T Y P E a p p U I D 0 x 1 0 0 0 3 9 C E 0 X 1 0 0 0 8 A C E V E N D O R I D 0 x 7 0 0 0 0 0 0 1 T A R G E T P A T H s y s t e m \ a p p s \ H e l l o W o r l d S O U R C E P A T H . S O U R C E H e l l o . c p p S O U R C E H e l l o A p p . c p p S O U R C E H e l l o D o c . c p p S O U R C E H e l l o A p p U i . c p p S O U R C E H e l l o A p p V i e w . c p p U S E R I N C L U D E . S Y S T E M I N C L U D E e p o c 3 2 \ i n c l u d e R E S O U R C E H e l l o . r s s L I B R A R Y e u s e r . l i b a p p a r c . l i b c o n e . l i b e i k c o r e . l i b You enumerate source files, specify
target and UIDs ( I will explain the
concept of UIDs later), then leave it to
the build system to perform the real
build. It's easy enough to be
appreciated. It's time to examine the previous
example step by step. T A R G E T H e l l o W o r l d . a p p T A R G E T P A T H s y s t e m \ a p p s \ H e l l o W o r l d T A R G E T T Y P E a p p The first step is to declare the target.
This is really the file name of the
compiled application. Note that an
application usually has MORE than one
file. At least for a GUI application there
is also a compiled resource file ( . r s c ) and an application information file (the . a i f ). Then you declare where in the phone the
application will be installed. The target type of a GUI application is
usually a p p . However it can be one of many. For example it can be e x e for an executable, or a mime-type
recognizer (m d l ), etc. Each of them has a special purpose not discussed
here. The UIDs: U I D 0 x 1 0 0 0 3 9 C E 0 X 1 0 0 0 8 A C E are used to uniquely identify the
application. See section 4.1 for details.
For an app, you always use 0 x 1 0 0 0 3 9 C E ; in this case you have also to specify the UID3. This a
unique application UID you can obtain
freely by sending a request email to
Symbian. The UID3 is essential since it
allows for distinguishing unique
applications. Now let's examinate the declaration needed to build the code: S O U R C E P A T H . U S E R I N C L U D E . S Y S T E M I N C L U D E e p o c 3 2 \ i n c l u d e These are the declarations required to
find the files to be compiled: source
path, user defined includes, standard
system includes. Of course what follows
is the list of source (and resource) files: S O U R C E H e l l o . c p p R E S O U R C E H e l l o . r s s Compiling sources you create object
files that must be linked against
libraries; so last step is to enumerate
the libraries required to the
applications. L I B R A R Y e u s e r . l i b a p p a r c . l i b c o n e . l i b e i k c o r e . l i b When you use a feature in SymbianOS,
you must locate which library it uses,
and add it to this list. If you forget
something, the application won't link.
Saturday, January 22, 2011
Installing the C++Builder, Javaand Perl
To install C++BuilderX, you have to
unzip the C B X 1 . 5 _ m o b i l e - R T M . z i p , and then run the contained setup.exe. After installation, start it and feed the
license you should have received by
email when you registered for it. After Installation, you have to copy: C : \ B o r l a n d \ C b u i l d e r X 1 . 5 \ b i n \ s d k t o o l s \ b s c m a k e into c : \ s y m b i a n \ M S D E V \ B I N . This tool is the missing one from the toolchain we obtained by
downloading Microsoft tools from
Internet. Now you have to install Java and Perl.
It seems a bit strange to have
windows-only development
environment built on GCC, Perl and Java
(all of them tools typical of an Unix
environment) but unfortunately this is the case. The whole toolchain could
easily be ported to Linux or OSX (and it
has been done) except for the emulator,
that heavily relies on the Windows API.
I believe this is the main reason
because Symbian does not provide a port for different development
environments. Let's continue the installation. Run
j2sdk-1_3_1_16-windows-i586.exe to
install Java version 1.3.1 Run APi518e.exe to install Active Perl
5.1.8e A restart is now highly recommended.
unzip the C B X 1 . 5 _ m o b i l e - R T M . z i p , and then run the contained setup.exe. After installation, start it and feed the
license you should have received by
email when you registered for it. After Installation, you have to copy: C : \ B o r l a n d \ C b u i l d e r X 1 . 5 \ b i n \ s d k t o o l s \ b s c m a k e into c : \ s y m b i a n \ M S D E V \ B I N . This tool is the missing one from the toolchain we obtained by
downloading Microsoft tools from
Internet. Now you have to install Java and Perl.
It seems a bit strange to have
windows-only development
environment built on GCC, Perl and Java
(all of them tools typical of an Unix
environment) but unfortunately this is the case. The whole toolchain could
easily be ported to Linux or OSX (and it
has been done) except for the emulator,
that heavily relies on the Windows API.
I believe this is the main reason
because Symbian does not provide a port for different development
environments. Let's continue the installation. Run
j2sdk-1_3_1_16-windows-i586.exe to
install Java version 1.3.1 Run APi518e.exe to install Active Perl
5.1.8e A restart is now highly recommended.
Symbian OS tutorial
Symbian is an operating system derived
from the Epoc operating system. Epoc
was developed by Psion for their
handhelds in the 80's. Symbian is an
evolution designed to be used in
mobile phones, and comes to real devices in different flavors. More precisely, Symbian Inc develops the base operating system and licenses
it out to phone manufacturers. Vendors
then build a user interface on top of the
base operating system. They can also
customize (and often do) the operating
system for a specific purpose; the bundle of the operating system plus the
user interface is shipped, with the
hardware to be sold on the market.
Currently the most widespread is the
Series60 platform, used by many Nokia
phones like the Nokia 6600 and many many other models. There also exists the UIQ platform, powering the Sony Ericcsson P800/
P900/P910i (see below the second
image) and the Motorola A1000/A1010. Also there are other flavors, like the
Series80 that powers the Nokia
Communicator series (Nokia 9500 and others) and the Series90, used currently
only by the Nokia 7710. There are rumors hovewer Series90 will fold in to
the Series 60 platform in the
foreseeable future.
Note that since there are MANY
versions of each combination OS/UI,
there is a different SDK for each combination. For example we can
enumerate the SDK for Series60 version
6.1, 7,0s, 8.0, 9.0 etc, and the SDK for
UIQ version 2.0, 2.1 etc.
You have to build application for
specific devices using the appropriate SDK of the correct version of the target
phone. Since our focus is on the Series 60
platform, it is useful to understand
which SDKs are available. This page clarifies a lot of things.
Basically we have editions of the SDK,
with enhancements, named Feature
Pack. The Nokia site enumerates the
following: SDK for 2nd Edition, FP 3, beta (FP =
feature pack) SDK for 2nd Edition, FP 2 SDK for 2nd Edition, FP 1 SDK for 2nd Edition SDK for 1st Edition, FP1 SDK for 1st Edition Unfortunately, for each combination of
edition and feature pack there are some
variants, depending on the target IDE
(Microsoft, Borland or CodeWarrior) to
be used, so the complete picture is a
mess. There is always a Command Line version (not bound to any IDE).
In this tutorial will stick with the plain
SDK, NOT the customized version,
although I will show you how to use it
(the PLAIN version, I repeat) with the C
++BuilderX IDE.Let's start by learning to install a free
but complete development
environment. Since my primary target
phone is the old (but good) Nokia 3660
I will depict how to install a complete
environment for "Symbian 6.1 Series 60 SDK 1.2" based on the C++BuilderX 1.5.
However, it is not very different to
install newer versions.
This is perhaps the best solution
available for free, and is complete with
a REAL IDE, with code completion, compilation and debugging support. It
is NOT easy to set up, since you have to
collect a lot of stuff from here and there.
There are many tutorials available on
the net, but definitely none of them is
complete or clear enough (in my opinion), which is why I am showing
you the way that worked for me.
DOWNLOADING
The Nokia SDK: Go http://www.forum.nokia.com/ main/0,,034-4,00.html
Choose "1St Ed FP1 MS&Borland", you
will download s60_sdk_v1.2.zip Choose "2nd Ed Visual Studio & .NET",
you will download: s60_sdk_v2.0.zip Choose "2nd Ed FP1 MS&Borland", you
will download: S60_SDK_v2.1_NET.zip The Borland IDE: Go http://info.borland.com/survey/ cbx15_mobile_edition.html
Register to Borland and ask for a key,
then download the CBuilderX 1.5 Microsoft Tools: Download the free VisualC++ Toolkit
from:
http://msdn.microsoft.com/visualc/
vctoolkit2003/
Download the Debugger from:
http://www.microsoft.com/whdc/ devtools/debugging/installx86.mspx
Download NMAKE from:
http://download.microsoft.com/
download/vc15/patch/1.52/w95/en-us/
nmake15.exe Additional Components: You need Active Perl 518. It is here:
http://ftp.activestate.com/ActivePerl/
Windows/5.005/Intel/APi518e.exe You need Java Runtime 1.3.1. It is
here: http://java.sun.com/j2se/1.3/
download.html
Visual C++ does not provide a separated
dumpbin or lib utility. This function is
embedded in the 'link' command;
unfortunately the SDK requires them. A solution is a wrapper to call 'link' as
'dumpbin' or 'lib'. Download these ones: dumpbin.exe lib.exe What's Next? Now that we have downloaded all the
required stuff, we can go on to the
installation. First, we install Microsoft
tools, then the C++BuilderX, and lastly
the Command line version of the SDK.
Once we have completed this procedure, we can check if everything is
working properly.
from the Epoc operating system. Epoc
was developed by Psion for their
handhelds in the 80's. Symbian is an
evolution designed to be used in
mobile phones, and comes to real devices in different flavors. More precisely, Symbian Inc develops the base operating system and licenses
it out to phone manufacturers. Vendors
then build a user interface on top of the
base operating system. They can also
customize (and often do) the operating
system for a specific purpose; the bundle of the operating system plus the
user interface is shipped, with the
hardware to be sold on the market.
Currently the most widespread is the
Series60 platform, used by many Nokia
phones like the Nokia 6600 and many many other models. There also exists the UIQ platform, powering the Sony Ericcsson P800/
P900/P910i (see below the second
image) and the Motorola A1000/A1010. Also there are other flavors, like the
Series80 that powers the Nokia
Communicator series (Nokia 9500 and others) and the Series90, used currently
only by the Nokia 7710. There are rumors hovewer Series90 will fold in to
the Series 60 platform in the
foreseeable future.
Note that since there are MANY
versions of each combination OS/UI,
there is a different SDK for each combination. For example we can
enumerate the SDK for Series60 version
6.1, 7,0s, 8.0, 9.0 etc, and the SDK for
UIQ version 2.0, 2.1 etc.
You have to build application for
specific devices using the appropriate SDK of the correct version of the target
phone. Since our focus is on the Series 60
platform, it is useful to understand
which SDKs are available. This page clarifies a lot of things.
Basically we have editions of the SDK,
with enhancements, named Feature
Pack. The Nokia site enumerates the
following: SDK for 2nd Edition, FP 3, beta (FP =
feature pack) SDK for 2nd Edition, FP 2 SDK for 2nd Edition, FP 1 SDK for 2nd Edition SDK for 1st Edition, FP1 SDK for 1st Edition Unfortunately, for each combination of
edition and feature pack there are some
variants, depending on the target IDE
(Microsoft, Borland or CodeWarrior) to
be used, so the complete picture is a
mess. There is always a Command Line version (not bound to any IDE).
In this tutorial will stick with the plain
SDK, NOT the customized version,
although I will show you how to use it
(the PLAIN version, I repeat) with the C
++BuilderX IDE.Let's start by learning to install a free
but complete development
environment. Since my primary target
phone is the old (but good) Nokia 3660
I will depict how to install a complete
environment for "Symbian 6.1 Series 60 SDK 1.2" based on the C++BuilderX 1.5.
However, it is not very different to
install newer versions.
This is perhaps the best solution
available for free, and is complete with
a REAL IDE, with code completion, compilation and debugging support. It
is NOT easy to set up, since you have to
collect a lot of stuff from here and there.
There are many tutorials available on
the net, but definitely none of them is
complete or clear enough (in my opinion), which is why I am showing
you the way that worked for me.
DOWNLOADING
The Nokia SDK: Go http://www.forum.nokia.com/ main/0,,034-4,00.html
Choose "1St Ed FP1 MS&Borland", you
will download s60_sdk_v1.2.zip Choose "2nd Ed Visual Studio & .NET",
you will download: s60_sdk_v2.0.zip Choose "2nd Ed FP1 MS&Borland", you
will download: S60_SDK_v2.1_NET.zip The Borland IDE: Go http://info.borland.com/survey/ cbx15_mobile_edition.html
Register to Borland and ask for a key,
then download the CBuilderX 1.5 Microsoft Tools: Download the free VisualC++ Toolkit
from:
http://msdn.microsoft.com/visualc/
vctoolkit2003/
Download the Debugger from:
http://www.microsoft.com/whdc/ devtools/debugging/installx86.mspx
Download NMAKE from:
http://download.microsoft.com/
download/vc15/patch/1.52/w95/en-us/
nmake15.exe Additional Components: You need Active Perl 518. It is here:
http://ftp.activestate.com/ActivePerl/
Windows/5.005/Intel/APi518e.exe You need Java Runtime 1.3.1. It is
here: http://java.sun.com/j2se/1.3/
download.html
Visual C++ does not provide a separated
dumpbin or lib utility. This function is
embedded in the 'link' command;
unfortunately the SDK requires them. A solution is a wrapper to call 'link' as
'dumpbin' or 'lib'. Download these ones: dumpbin.exe lib.exe What's Next? Now that we have downloaded all the
required stuff, we can go on to the
installation. First, we install Microsoft
tools, then the C++BuilderX, and lastly
the Command line version of the SDK.
Once we have completed this procedure, we can check if everything is
working properly.
Sunday, March 15, 2009
Installing and checking the SDK 1.2
Now we can install and check the SDK
version 1.2. I use this for maximum
compatibility (at the time of this
writing it is the oldest available). I own
a Nokia 3660 so I wish to compile
programs compatible with the series 60 platform 1.x. Other SDKs have similar
installation procedures. Unzip n 6 0 _ s d k _ 1 _ 2 . z i p , and then run the contained s e t u p . e x e . Perform the following test to check if it
is working: > c d C : \ S y m b i a n \ 6 . 1 \ S e r i e s 6 0 \ S e r i e s 6 0 E x \ f o r m \ g r o u p > b l d m a k e b l d f i l e s > a b l d b u i l d w i n s u d e b You should expect NO error messages.
Unfortunately, sometimes Perl may not
be able to find an E n v 3 2 . p m file. To fix this problem I simply edited: C : \ S y m b i a n \ 6 . 1 \ S h a r e d \ E P O C 3 2 \ T o o l s \ B L D M A K E . B A T and changed p e r l - S b l d m a k e . p l % 1 % 2 % 3 % 4 % 5 % 6 % 7 % 8 % 9 into: p e r l - I c : \ s y m b i a n \ 6 . 1 \ s h a r e d \ e p o c 3 2 \ t o o l s - S b l d m a k e . p l % 1 % 2 % 3 % 4 % 5 % 6 % 7 % 8 % 9 The problem is that for some strange
reason, some Perl libraries are placed in
a different directory and not in the
default Perl search path. This way, I
simply told the Perl interpreter where
to find the missing E n v . p m. To test if the build works, launch the
emulator, using the icon installed in the
start menu for your SDK. You should see
(as one of the latest icon of the
emulated phone menu) an icon with
the name "Form". Clicking on it will launch the example (that we just
compiled) straight in the emulator.
Enjoy a demo of the available form
options for the Symbian Series 60
platform! Well, if everything is working in the
emulated environment, maybe you are
wondering if things work in the real
one, your phone. You can now check if
you are able to build an installer for a
phone. Run these commands: > a b l d b u i l d t h u m b u r e l > c d . . \ s i s > m a k e s i s You should end with a . s i s file in your directory. Send it to your phone
(by Bluetooth or other means) and if
your phone is SDK 1.2 compatible, the
installation will perform just fine and
the application will run in the same
way it worked in the emulator.
version 1.2. I use this for maximum
compatibility (at the time of this
writing it is the oldest available). I own
a Nokia 3660 so I wish to compile
programs compatible with the series 60 platform 1.x. Other SDKs have similar
installation procedures. Unzip n 6 0 _ s d k _ 1 _ 2 . z i p , and then run the contained s e t u p . e x e . Perform the following test to check if it
is working: > c d C : \ S y m b i a n \ 6 . 1 \ S e r i e s 6 0 \ S e r i e s 6 0 E x \ f o r m \ g r o u p > b l d m a k e b l d f i l e s > a b l d b u i l d w i n s u d e b You should expect NO error messages.
Unfortunately, sometimes Perl may not
be able to find an E n v 3 2 . p m file. To fix this problem I simply edited: C : \ S y m b i a n \ 6 . 1 \ S h a r e d \ E P O C 3 2 \ T o o l s \ B L D M A K E . B A T and changed p e r l - S b l d m a k e . p l % 1 % 2 % 3 % 4 % 5 % 6 % 7 % 8 % 9 into: p e r l - I c : \ s y m b i a n \ 6 . 1 \ s h a r e d \ e p o c 3 2 \ t o o l s - S b l d m a k e . p l % 1 % 2 % 3 % 4 % 5 % 6 % 7 % 8 % 9 The problem is that for some strange
reason, some Perl libraries are placed in
a different directory and not in the
default Perl search path. This way, I
simply told the Perl interpreter where
to find the missing E n v . p m. To test if the build works, launch the
emulator, using the icon installed in the
start menu for your SDK. You should see
(as one of the latest icon of the
emulated phone menu) an icon with
the name "Form". Clicking on it will launch the example (that we just
compiled) straight in the emulator.
Enjoy a demo of the available form
options for the Symbian Series 60
platform! Well, if everything is working in the
emulated environment, maybe you are
wondering if things work in the real
one, your phone. You can now check if
you are able to build an installer for a
phone. Run these commands: > a b l d b u i l d t h u m b u r e l > c d . . \ s i s > m a k e s i s You should end with a . s i s file in your directory. Send it to your phone
(by Bluetooth or other means) and if
your phone is SDK 1.2 compatible, the
installation will perform just fine and
the application will run in the same
way it worked in the emulator.
Wednesday, February 11, 2009
Building programs with the SDK
The numerous Symbian SDKs share a
special build system developed by
Symbian for the use specifically with
the SDK. Some of the Symbian IDEs
build on top of it, in order to provide
integration with the SDK. C++BuilderX in particular integrates with the default
build system very well. Although there exist alternative ways
to build things for Symbian (as the
Rudolf König SDK on Unix using plain
GNU Makefile), the Symbian build
system is somewhat standard in the
Symbian C++ world. So I believe that it must be known by every Symbian C++
programmer and I will teach you how
to use and develop applications with it. A Symbian application source usually
stores, in a directory named 'group', the
file 'bld.inf' and one or more files with
extension '.mmp'. You define the build
for your Symbian application by writing b l d . i n f and at least one p r o j e c t . mm p . Then you process these files with a tool named
'bldmake' and will obtain a batch file
('ABLD.BAT') and some makefiles that
will build the application for you. This tool exists mainly because a
Symbian application is usually built for
many platforms: the emulator, using a
Microsoft X86 compiler, as well as the
real device using a gcc-derived ARM
compiler. The b l d m a k e saves you from writing specially crafted makefiles
for these compilers and make utilities;
also it allows for building many targets
with just a single command. In fact, 'bldmake' is quite easy to use IF
you accept the way it works. If you
don't, you will suffer endless
nightmares in order to build things the
way you want. Another drawback is
the fact that it is somewhat slow, so you have to compile, build and start the
emulator, and always wait some time
in the middle of the process. Let's explain how it works with an
example. Open a command line prompt,
and after changing to the directory
containing the b l d . i n f , t y p e : > b l d m a k e b l d f i l e s Of course, you must have the PATH set
correctly for the installation of the SDK
you are using. This command will look
for the b l d . i n f , process it and the related * . mm p , then generate a BATCH file named A B L D . B A T . Now you have all you need to build your
applications. Simply type: > a b l d b u i l d This will build your application in all the
available flavors. Well, in fact you are
building eight (!) different binaries. Note
that the target files are stored in a very
deep directory structure, and you are
building both in debug and release versions for WINS (windows), ARM4
(plain arm), ARMI (speed optimized
arm), THUMB (size optimized ARM)! But
you can choose to build for only one
target, and since it take less time, you
usually build ONLY for one version of one target. For example, to build for the
emulator only in the debug version, or
for the device, optimized for size, in
release version, you type: > a b l d b u i l d w i n s u d e b > a b l d b u i n d t h u m b u r e l Building for Windows is enough to start
the emulator and run the application in
the emulated environment. Application
files are compiled and placed straight
where the emulator can run it: no need
to copy them in the right location. But for real devices, you have to pack
everything in a . s i s file for installation, send it to the phone and
install the application. You are required
to write a . p k g file to describe the installer, and then create it with: > m a k e s i s f i l e . p k g References:
BldMake
ABLD
Submenu
2.1 Binary Files
2.2 Source Files
2.3 The build process
2.4 The .mmp
2.5 The AIF
2.6 Create an installer
special build system developed by
Symbian for the use specifically with
the SDK. Some of the Symbian IDEs
build on top of it, in order to provide
integration with the SDK. C++BuilderX in particular integrates with the default
build system very well. Although there exist alternative ways
to build things for Symbian (as the
Rudolf König SDK on Unix using plain
GNU Makefile), the Symbian build
system is somewhat standard in the
Symbian C++ world. So I believe that it must be known by every Symbian C++
programmer and I will teach you how
to use and develop applications with it. A Symbian application source usually
stores, in a directory named 'group', the
file 'bld.inf' and one or more files with
extension '.mmp'. You define the build
for your Symbian application by writing b l d . i n f and at least one p r o j e c t . mm p . Then you process these files with a tool named
'bldmake' and will obtain a batch file
('ABLD.BAT') and some makefiles that
will build the application for you. This tool exists mainly because a
Symbian application is usually built for
many platforms: the emulator, using a
Microsoft X86 compiler, as well as the
real device using a gcc-derived ARM
compiler. The b l d m a k e saves you from writing specially crafted makefiles
for these compilers and make utilities;
also it allows for building many targets
with just a single command. In fact, 'bldmake' is quite easy to use IF
you accept the way it works. If you
don't, you will suffer endless
nightmares in order to build things the
way you want. Another drawback is
the fact that it is somewhat slow, so you have to compile, build and start the
emulator, and always wait some time
in the middle of the process. Let's explain how it works with an
example. Open a command line prompt,
and after changing to the directory
containing the b l d . i n f , t y p e : > b l d m a k e b l d f i l e s Of course, you must have the PATH set
correctly for the installation of the SDK
you are using. This command will look
for the b l d . i n f , process it and the related * . mm p , then generate a BATCH file named A B L D . B A T . Now you have all you need to build your
applications. Simply type: > a b l d b u i l d This will build your application in all the
available flavors. Well, in fact you are
building eight (!) different binaries. Note
that the target files are stored in a very
deep directory structure, and you are
building both in debug and release versions for WINS (windows), ARM4
(plain arm), ARMI (speed optimized
arm), THUMB (size optimized ARM)! But
you can choose to build for only one
target, and since it take less time, you
usually build ONLY for one version of one target. For example, to build for the
emulator only in the debug version, or
for the device, optimized for size, in
release version, you type: > a b l d b u i l d w i n s u d e b > a b l d b u i n d t h u m b u r e l Building for Windows is enough to start
the emulator and run the application in
the emulated environment. Application
files are compiled and placed straight
where the emulator can run it: no need
to copy them in the right location. But for real devices, you have to pack
everything in a . s i s file for installation, send it to the phone and
install the application. You are required
to write a . p k g file to describe the installer, and then create it with: > m a k e s i s f i l e . p k g References:
BldMake
ABLD
Submenu
2.1 Binary Files
2.2 Source Files
2.3 The build process
2.4 The .mmp
2.5 The AIF
2.6 Create an installer
Thursday, January 22, 2009
Installing Microsoft tools
Note: we will choose special installation
directories (not the default ones!) in
order to prevent some problems which
can arise if we use the installation
directories containing spaces in file
name (that is the case if we stick with the default suggestion).
Run the installer VCToolkitSetup.exe.
Since installation path containing spaces
can generate problems, I will
recommend that you to install it to a
directory without spaces in the name. Also installing in drives different from C:
can give you some problems, so I
recommend installing it in: C : \ S y m b i a n \ M S D E V This will create c:\Symbian\MSDEV\bin
(and other directories).
Now we can install the debugging
tools, running d b g _ x 8 6 _ x . y . e x e . This installer won't create ANY bin
subdirectories, placing the cdb.exe
(required for the debugging support) in
the top level of the installation
directory. So I suggest you to choose,
(in order to have all the required tools in the same place), this one: C : \ S y m b i a n \ M S D E V \ b i n Now you can install n m a k e , executing nmake15.exe: it will
decompress n m a k e . e x e and n a m a k e . e r r . Copy both of them to C : \ S y m b i a n \ M S D E V \ b i n The next step is to copy l i b . e x e and d u m p b i n . e x e to: C : \ S y m b i a n \ M S D E V \ b i n Now you have to add, to the system (or
user) path, the directory C : \ S y m b i a n \ M S D E V \ b i n . To do so, go to the control panel, choose
system, select advanced and click on
the button 'Environment Variables'.
Depending on your locale, icons and
option names will be translated in your
language. Now you have a dialog. Choose in the System Panel the entry
'PATH' and edit it by double clicking. At
the beginning add C : \ S y m b i a n \ M S D E V \ b i n ; . Note the ';' at the end, it is essential to separate
things. If you forget it, things simply
won't work. As a check, open a
command prompt and type 'nmake'. If
you get 'command not found' or
equivalent, you made a mistake in configuring the path. NOTE: if you get
'makefile not found' or similar, then you
are right: nmake is working (only it
does not find a makefile, but at this
stage it is not supposed to do so).
Congratulations! You have installed the required Microsoft tools for the Symbian
SDK.
directories (not the default ones!) in
order to prevent some problems which
can arise if we use the installation
directories containing spaces in file
name (that is the case if we stick with the default suggestion).
Run the installer VCToolkitSetup.exe.
Since installation path containing spaces
can generate problems, I will
recommend that you to install it to a
directory without spaces in the name. Also installing in drives different from C:
can give you some problems, so I
recommend installing it in: C : \ S y m b i a n \ M S D E V This will create c:\Symbian\MSDEV\bin
(and other directories).
Now we can install the debugging
tools, running d b g _ x 8 6 _ x . y . e x e . This installer won't create ANY bin
subdirectories, placing the cdb.exe
(required for the debugging support) in
the top level of the installation
directory. So I suggest you to choose,
(in order to have all the required tools in the same place), this one: C : \ S y m b i a n \ M S D E V \ b i n Now you can install n m a k e , executing nmake15.exe: it will
decompress n m a k e . e x e and n a m a k e . e r r . Copy both of them to C : \ S y m b i a n \ M S D E V \ b i n The next step is to copy l i b . e x e and d u m p b i n . e x e to: C : \ S y m b i a n \ M S D E V \ b i n Now you have to add, to the system (or
user) path, the directory C : \ S y m b i a n \ M S D E V \ b i n . To do so, go to the control panel, choose
system, select advanced and click on
the button 'Environment Variables'.
Depending on your locale, icons and
option names will be translated in your
language. Now you have a dialog. Choose in the System Panel the entry
'PATH' and edit it by double clicking. At
the beginning add C : \ S y m b i a n \ M S D E V \ b i n ; . Note the ';' at the end, it is essential to separate
things. If you forget it, things simply
won't work. As a check, open a
command prompt and type 'nmake'. If
you get 'command not found' or
equivalent, you made a mistake in configuring the path. NOTE: if you get
'makefile not found' or similar, then you
are right: nmake is working (only it
does not find a makefile, but at this
stage it is not supposed to do so).
Congratulations! You have installed the required Microsoft tools for the Symbian
SDK.
Subscribe to:
Posts (Atom)