S60 Open to new features

The Carbide.c++ 1.3 builder depends on the underlying Symbian OS command line. But the Symbian command line system had some limitations and problems that were addressed to improve performance and make it simpler for the user to build his project. What were some of these improvements we did to make a better build system? Let's talk about them now.

The existing Symbian command line uses 'abld build' when building the project. This results in calls to 'abld export', 'abld makefile', 'abld library', 'abld resource', 'abld target' and 'abld final' respectively.

Problem 1: Dependency generation in the makefile stage

A big performance issue is with the generation of makefiles at the 'abld makefile' stage. The makefiles generated by Symbian's command line system contain dependency information for all source and resource files in the MMP. Most of the time it takes to generate makefiles is spent calculating dependencies. The time it takes to create each makefile is directly proportional to the number of source and resource files that it needs to calculate dependency information.

The makefile is generated as a whole which is very inefficient. If a single source file is changed, the dependency information may have changed for only that single source file. But it will be regenerated for all source files when the makefile is regenerated, including the source files that have not changed.

Solution: Dependency tracking is done by the compiler

To fix this problem we seperated the dependency information from the makefiles generated by 'abld makefile'. All of the compilers used by Symbian (WINSCW,RVCT, GCCE) support dumping of dependency information to a file. So we allow the compilers to do the dependency generation and include these files in the makefiles. We also make sure that dependency files (.d) are in the same working directory as the object code and fix any paths in the dependency files so they match the paths in the makefiles.

Problem 2: Tracking mmp changes

Also, the Symbian command line build tools do no tracking of mmp changes, so even if nothing has changed in an mmp or any of it's includes, the call to 'abld makefile' will still generate the makefile, including it's dependencies. If neither an mmp file nor any of it's includes have been modified there should be no need to regenerate the makefiles. This would work with the exception of changes to dependency information for source and resource files. If a change were made to a #include within an mmp, the dependency information in the makefile would be 'stale' and subsequent builds would be inaccurate

Solution: Builder detects changes to the MMP

If the change to the MMP file affects compiling , the entire MMP file should be re-compiled and linked. If the option affects linking, only a re-link occurs. If the change affects neither compiling nor linking then no build should take place.

We now track changes to the MMP and give the user three options that tell the build system what to do with the file.. It's called "Show a dialog to modify build actions when modified MMP's are detected". It's in the global workspace settings (Window > Preferences > Carbide.c++ >Build) and project settings (Properties > Carbide.c++ > Carbide Project Settings). If the project setting is set it overrides the workspace setting. The three options offered are a) Compile and Link b) Link only c) None.