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