Harry Li's Forum Nokia Blog

A Generic Makefile build script for Symbian

2009-02-10T23:46:01+07:00

In the past days, I have made a build scripts which utilizes a couple of files to build a S60 project in a faster and simpler way. Gnu Make is the main actor in this solution, and this is inspired by the Mozilla project. The main feature of the building is that its much faster than Carbide.c++ IDE and command line build because here I only take care of a set of parameters used in a project, the rest of them are omitted.

Build with this "Gnu Make for Symbian", you need three files Makefile, defines.mk and config.mk in myapp\gms path. Then you need to install MSYS . Also three environment parameters should be set like this:

SYMBIAN_SDK_PATH = /c/symbian/9.1/s60_3rd_mr/
ACTIVE_PERL = /c/perl/bin/perl.exe
CC_INSTALL_PATH = /c/Program\Files/CSL\ Code\ Sourcery

Please be noted the first one should contains a trailing slash like classic EPOCROOT environment variable. The second one is the ActivePerl .exe file used by some resource compiler script. The last one is the path to GCCE compiler installation path, without trailing slash. If there are spaces in any of them, please use "\ " backslash with a space instead.

After all these done, you could change your working directory into the build home bye "cd /c/myapp/gms". Then "make build" will do the build and "make pack" will also do the makesis work.

A sample config.mk file is shown below. I guess probably everything is explained by its name.

PROJECT_NAME = helloworld
TARGET_TYPE = EXE
UID2 = 0
UID3 = A000ABCD
SECUREID = A000ABCD
EPOCSTACKSIZE = 0x5000
CAPABILITY = NONE
SYSINCLUDE = $(EPOCROOT)/include
USERINCLUDE = ../inc
CXXSRCS = \
        helloworld.cpp \
        $(NULL)
CSRCS = \
        helloworld.c \
        $(NULL)
IMG_SRCS = ../gfx/icon.svg
IMG_TARGETS = $(DIST_PATH)/$(PROJECT_NAME)_aif.mif
IMG_ARGS = /c32
RSS_TARGETS = $(DIST_PATH)/$(PROJECT_NAME).rsc $(DIST_PATH)/$(PROJECT_NAME)_reg.rsc
LANG_MACRO = -DLANGUAGE_SC
SYSLIBRARY = euser.lib estlib.lib avkon.lib
CERT = /c/cert/selfsigned.cer
KEY = /c/cert/selfsigned.key

Although there are a number of limitations in this script, hope you like this tiny thing and in future I will fill it more powerful :)

Finishing the immigration to GNU make

2008-08-01T14:38:28+08:00

During last couple of weeks, I made the immigration of building Mozilla NSPR component with Carbide.C++ (still based on makemake and friends Perl scripts) to GNU make and autoconf friends. Here I will share some points I learned in this process.

First of all, if your open source project uses a lot of Writable Static Data (WSD), in theory even only one single variable, and they are used in dynamically linked library (DLL) target type, then your only choice is buying a RVCT compiler. Because GCCE compiler which ships with the S60 SDK has a defect that can not build a working DLL binary if there is WSD in it. This known bug is documented by Symbian already. Though in the document Symbian stated the problem is solved in a later GCCE release possibly, yet I had tried all GCCE releases which is later than 2005Q1C, then found some of them will generate an internal compiler error and some of them build the same defective binary almost the same as 2005Q1C. So I think I could give you the advice : try only GCCE compiler tools if it is shipped with Nokia or Symbian, otherwise you are spending your time on what has been proven already.

Then let's get back to the build tool chain immigration affair. Actually I observed all original makmake build process in Carbide.C++, and then try to copy all compiler and linker arguments to GNU make Makefile scripts. The work is not so hard, and the result is also convenient to verify. Here are some brief points need your attention:

Compiler/linker arguments are main additions feed to Makefile
Emulator builds and target device builds use different compiler/linker
Device builds will need post linker operations, elf2e32 is the tool we use
ActivePerl is used to calling the .RSS resource file compiling, other Perl probably won't work
Building statically linked library (.LIB target type) takes no post linker jobs to do, compared with .DLL and .EXE

Also, it really depends on the project scale you are working with. Like Mozilla NSPR component, it uses several config and make rules files to make targets for over two dozens operating systems, then finding which place is proper to add arguments takes longer than making the modify itself.

Finally, you could have a look at Bug 442706, the patch there will show you the modifications made against the original NSPR build scripts. A detailed description about how to build NSPR with GNU make/autoconf can be found at Mozilla Wiki.

Cheers~

Evaluate the project before porting

2008-05-08T09:16:10+08:00

Porting an open source project is quite different from developing a new application for mobile phones. During past days without Open C, we have to rewrite lots of code to satisfy both Symbian OS rules/limitation and difference between mobile devices and desktop computers. Touching so much code will cost more development time, but what's worse is that making changes too much will drive you thinking "Should I start a new project rather than using only a little from this existing project?". So porting an existing application onto Symbian OS makes you keep concerning how much modification will you make, if too much consider starting a new one or just share the name or brand. As far as I know, HelixCommunity is the first big and famous open source project ported to Symbian OS, and it supports as early as v6.1. I checked out its source in 2004 (means their code nowadays might be different a lot), this is one example of making too much changes so you can tell few difference between porting like this or making a new project. Since S60 3rd Edition, there is Open C we can utilize, the job is easier. But still we can not ignore this consideration because of the nature of mobile phones. In one word, first step of porting an existing project is evaluate how much changes will be made approximately.

This document in Forum Nokia web site is very helpful, and generally speaking smaller projects are always easier to make decision if it could be ported than bigger ones. Smaller ones are always based on some existing framework, if the framework exists or can be ported on Symbian OS then the project itself will be fine in most cases. Huge project like Mozilla or Helix will give us an impression that it is likely impossible to port cause it has so many dependencies and self owned framework. However, we want eveidence to support our decision. Let's get back to Mozilla, after searching its website, there is an "C/C++ Portability Guide" which shows us an amazing likeness of Symbian OS programming limitations. From this article, we could learn Mozilla code will probably contain very little exceptions, RTTI and others that Symbian OS C++ does not support. Then with the help of Open C, we could have better confidence about porting without changing too much code.

Next we have to make deeper research on the inner structure of Mozilla platform, cause you can not start portting any piece of code without knowing which level it lies in and what it does actually. Stay tuned, I will bring more as the work goes on