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 :)

Hello folks, it's really a long time since my last post. Because of the busy schedule of my own company's project, I'm actually away from the Mozilla platform porting effort for a while. So it's a bit embarrased to carry out fresh experiences to share with you at this moment. However I will try to demostrate a testing trick which I learned from NSS (Network Security Service) testing section.

Probably all Unix gurus like the powerful shell script, and it is commonly used for testing purpose. In NSS the test cases are all called by several complex shell scripts, and there is a very flexibility to extend usage of these tests caller scripts. Unluckily we don't have a shell script executing environment on Symbian OS. But I was borrowing ideas of this testing method, by writing a console application and treat it as the main body to coordinate all test cases.

Here are some notes:

• We use a config file to tell the tests caller which executables we want to call, their executable image names, the calling arguments, and expected return code. 
• There is a log file to log all activities about test cases calling time and return value status.
• Frequently adjusted variables are defined at header as MACROs, like log file name and storage path. Please note STDIO_FILE macro should be defined the same as the standard output file in your C:\System\Data\config.ini
• You could control test cases running mode, by add either pause before run every test or pause after every test case or both.

I hope this trick will help you on porting massive test cases project onto Symbian OS. And also if you have any comment on this, please feel free to send your comment.

Attachment 1 : source file, run_tests_symbian.cpp
Attachment 2 : example config file, tests.cfg

Cheers~ :p

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

Cheers~ 

Everyone who develops native Symbian C++ application knows that we use BLD.INF and *.MMP files to define a project. This is used since the very ancient Nokia 9200 SDK. The reason that Symbian uses this approach is quite similar with the reason Symbian made other unique features : because mobile devices have unique characteristics other than desktop computers. There is no UID for each appilcation on a desktop OS, also there is no compile time check on global writable static data use.

However, when porting open source project like Mozilla to Symbian OS, it becomes very impractical to stick with the original BLD.INF plus *.MMP solution. There are a number of reasons:

• Portability :
  Mozilla project is something we could treat it as a platform, framework or midware. So portability is something the community considers as the first requirement. The community maintains one code repository to generate binary executables for dozens of OS/CPU arch. combinations. So we can't say that you build everything except Symbian platform with GNU make while building Symbian targets with another tool chain. 
  
• Community compatibility :
  We know the success of open source projects benefit from hundreds and thousands of developers around the world. The philosophy behind this doesn't mean we get software products without paying since they love contributing, it means they may be different experts on different sub-system. So we can't imagine that in future the FireFox for S60 has a security problem, a security expert has to learn how to build FireFox for S60 with BLD.INF and *.MMP for some time before he can get hands on the point of problem.
  
• Large scale :
  Because the code base and the number of components are quite large, it would be very difficult to write a BLD.INF to build the whole platform which you might noticed in my earlier blog. That's also a nature of the scale limitation of Symbian's own build system compared with GNU make. As a derived reason we have to use Mozilla's build system, the community have to run a server to build the whole source tree every several hours because with such a large code base almost every hour there are codes checking into the repository, then the old Symbian's build method will have to be modified heavily to suite this automatically build monitoring system.

During the debugging and unit test cases running phase, open source projects usually write error string or other information to STDERR file. Quite unluckily, we can not retrieve lines from STDERR in Symbian with Open C. The stdioserver program comes with Open C SDK only redirects STDOUT to a file located on disk, but left STDERR no where to check out.

So in my Mozilla porting days, I have to make a workaround for retrieving information written to STDERR because most of unit test cases write error information to STDERR. There are two workarounds which could be used according to different situation.

If you have only one or not so many .c source files to fix, then I would like to recommend the first way. That is to modify the source code, add these lines as the top most statement:

FILE* stderr_redirect = freopen("C:\\data\\stderr.log", "w", stderr); // Top most line
/* Begin of original code lines */
...
...
...
/* End of original code lines */
fclose(stderr_redirect); // Bottom most line

The other case is that you have many (maybe up to several hundreds) independent .c source files,  so it's almost impossible to adopt  the first way, like NSPR test cases. We have to figure out another solution. Here I did a small trick, that is modify the stdio.h in <EPOCROOT>\Epoc32\include\stdapis in Open C SDK. The stdio.h in looks like this:

...
...
#ifndef __SYMBIAN32__
#define    stdin    __stdinp
#define    stdout    __stdoutp
#define    stderr    __stderrp
#else
__BEGIN_DECLS
IMPORT_C FILE *__stdin  (void);
IMPORT_C FILE *__stdout (void);
IMPORT_C FILE *__stderr (void);
IMPORT_C char * tmpdirname(void);
__END_DECLS
#define stdin       (__stdin())
#define stdout  (__stdout())
#ifdef STDERR_TO_STDOUT
#define stderr  (__stdout())
#else
#define stderr  (__stderr())
#endif
#endif
...
...

These lines are located around line 265 - 283 if you are using Open C SDK v1.3. With the lines shown as light yellow marked, you could know I just let the compiler treats STDERR as STDOUT, sothat information written to STDERR are all redirected to STDOUT. Of course we have to define MACRO STDERR_TO_STDOUT in that .MMP file. And because we don't want this trick infect other projects which don't have their STDERR touched, so we use this macro to mark the  fence. Once STDERR is redirected to STDOUT, then you could use the original stdioserver program comes with the Open C SDK to check out original STDERR information in STDOUT file.

All two ways are easy to understand and use, although I felt the latter one is not so perfect because this requires changing a SDK file. Hope this tip will be helpful in your daily work, and just give me any comments when you get any idea about this.

Open C is a quite powerful tool when porting open source projects to Symbian OS platform. But a mobile kitty is not a desktop monster, it doesn't have a so powerful kernel, especially you encountered some design limitations. For small projects which don't utilize lower or system level functions, you will wield Open C without any pain. However, projects as large as Mozilla will meet the limitations and avoid using incomplete or absent functions. So marking those limitations with good documentation and practical experiences is very important. Here I will try to tell you some of my experiences.

First of all, you need to read Open C documents carefully, Nokia and Symbian try to explain every limitation they know as clear as possible. So you don't need go discussion board and ask questions before check the documents. *BUT ACTUALLY*, the problem is not all about checking Open C documents, there are possibilities the problem is not caused by Open C but your code. In this case, the situation is not easy. You need practical experiences from others, by talking with colleagues or searching discussion board.

Here comes the body. The most incomplete group is libc Signal Handling, but what's lucky is we can find absence of these functions, you don't need to determine where the problem comes from, your code or Open C. The second hard one to over come is using posix_spawn() instead of fork() and exec(). Here I would give you a suggestion, read the complete fork() manual and compare the difference between posix_spawn(). Then check the context of your code, see if these differences applied. This technique is not so easy, even there are further hidden side effect, for example "In the child process created with popen3/popen/system/posix_spawn, operations on the inherited file may cause a panic." in P.I.P.S. V1.3 Release Notes. Bear in mind those side effects from practice, then the job would be less tough.

With two big stop showers ahead, I think the most important is not getting those limitations one by one, but a skill to find if the bug comes from _my_ code or Open C. Once the debug tricks are at hand, there won't be anything "won't fix" 

In Symbian C++ development, MMP file is used to define a project. For large or complex project, often it is needed to gather some switches in a place act as configuration file, so different target could be made by changing configurations while the rest project file stay untouched. With help of MACROs we could get this done. Probably most of us had very smooth experience when using MACROs in their .cpp or .c files, but using MACROs in MMP is not so pleasant.

Before starting my words, it is good to revise MMP file syntax and related information from Symbian Developer Library. From the document we know MACROs for source files (.CPP) could be set by MACRO statement. But what about using conditional flow control in MMP file? I guess you must have examined the "hellowordbasic" example comes with S60 SDK 3rd Edition, and probably you have used this in MMP for a S60 3rd project: 

#ifdef WINSCW
TARGETPATH        \private\10003a3f\apps
#else
TARGETPATH        \private\10003a3f\import\apps
#endif

This told us preprosessor which deals with MACROs is used in MMP and many built-in MACROs are used, for example WINSCW, EKA2 and so on. With the power of MACROs in MMP we could do many, maybe the first one you want is using one MMP for one application with two (SymbianSigned and self-sign) UIDs. See below:

TARGET    MYAPP.exe
#if defined (M_SELFSIGN)
UID       0x100039CE 0xA000ABCD
#else
UID       0x100039CE 0x20006789
#endif

Obviously, this single MMP with two possible UIDs reduces many labors. Yet lines shown above is not complete. You have to define M_SELFSIGN in an earlier place. We mentioned "gather configuration switches in one place" in the beginning, so we make a "config.h" and include it in our MMP by add #include "config.h" line before TARGET statement. The content of config.h could contain:

#ifndef __CONFIG_H__
#define __CONFIG_H__
/* Switches */
#define S_SELFSIGN
#define S_ANOTHER_SWITCH
/* BODY */
#ifdef S_SELFSIGN
#define M_SELFSIGN
MACRO __SELFSIGN__
#endif //S_SELFSIGN
#endif //__CONFIG_H__

In this config.h file, we have two sections. First one is switches and the second one is body statements used in MMP. You could see with help of #define M_SELFSIGN , we can use conditional control flow in our MMP file, so two UIDs are applied in one single MMP. If you want to use SymbianSigned UID, just comment the #define S_SELFSIGN . Also we add a MACRO statement so that .CPP file could know this switch too.

Macro is a powerful tool, wielding this could reduce many of your labor work. I hope you could get insights by reading this, and glad to hear feedbacks on tricks of this kind.

It's quite a while since my last post. Although I'm not there, just because of the terrible earth quake happened in SiChuan China, I can't sleep well and concentrate on my codes while people there are suffering. God bless them, hope they could recover with time passes.

Actually this has been done two weeks ago. After evaluate the amount of porting works, we could go on with the dependency check of a specific project. For Mozilla, I had shown a framework picture:

From this picture we know the components in the lowest level are "NSPR" and Cairo". Because "Cairo" is only a graphics base, so we will start from NSPR first. 

For other open source projects without such a components diagram, then how we could know its internal components dependency? I would sugguest taking a look at the build(configure && make) output, from this log everything is exposed even with any third party library used by that project. Anyway, large projects like Mozilla will take us more time to get everything clear. Also the more time we put on dependency check, the more clear we could get for a structural view, and the more easy for add or modify codes.

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

Greetings Everybody! I have been a Forum Nokia Champion for over 1.5 years. Currently my major technology profession is developing native Symbian OS C++ applications mainly on S60, also I know some Python(PyS60), J2ME and Windows Mobile. Since last month I started concentrate my focus onto a very nice community, the famous Mozilla project. As I expressed before, I always feel extremely exciting about contributing my effort to something which will bring us openness, opportunities and freedom, just like the award winning desktop browser FireFox, and the possibility of running it on Symbian OS.

Frankly, at first I hadn't realized the size of the Mozilla Platform, until I read these from the book "Rapid Application Development with Mozilla":

It is 30 times larger than the Apache Web Server, 20 times larger than the Java 1.0 JDK/JRE sources, 5 times bigger than he standard Perl distribution, twice as big as the Linux kernel source, and nearly as large as the whole GNOME 2.0 desktop source—even when 150 standard GNOME applications are included.

Maybe the information from this book is a little out of date, also maybe size can not tell everything about an open source project. But what we could learn is that porting Mozilla platform onto Symbian OS will be a huge project which needs lots of hours, especially for those mobile developers with little Mozilla hacking experiences.

Here I'd like to share something I found in last 2 weeks digging, maybe some of you might become future contributor of Mozilla/FireFox on mobile devices. Also the reason I start my blogging about porting Mozilla onto Symbian OS is to continue the philosophy of open source software: making the development process and result product open, clear and collaborative.

• It's important to know Mozilla well before get hands on code. Read their websites well, know more about open source, vision of Mozilla, historical event, maybe the unique culture from Mozilla people.
• Mozilla platform is layered/modularized into several components, you could find the framework diagram in this blog.
• Beginners should know where to find information or documents about Mozilla platform. There are two wikis which may confuse you: Mozilla Developer Center whose audience are mainly Mozilla platform technology users, clients, documents in this wiki are set to stone; Mozilla Wiki which shows articles in engineering stage, you could find useful information about "Mobile" in this wiki. There is another non-wiki portal with lots of well categorized documents, http://www.mozilla.org/developer/
• Mozilla developers like IRC, meet them and feel free to ask your question at irc://irc.mozilla.org/mobile. If the link does not work for you, probably you'd like to have a FireFox with ChatZilla install.

There are a lot about porting Mozilla onto Symbian in the beginning days, I would like to write them down as time passes. I want to know more friends on this topic too, together we could make mobile Internet better with our efforts.

As part of my first blog, I want to say my thanks to Forum Nokia for providing us such a good chance to express our technology thoughts on mobile development. With this Forum Nokia Champion program I believe Forum Nokia community could be more and more popular, bring us more and more success stories one after another :)