Another build issue we addressed in Carbide 1.3 was a performance issue concerning compile times when compared to CodeWarrior. CodeWarrior has an option to run compiles concurrently, which reduced overall build time signficantly. Make has a similar feature which can be enabled with the -j switch. When specified it will run the make rules concurrently in multiple jobs and thus the compilation time will be faster. This works on multi-core and hyper-threaded machines.

Make will spawn N non-dependent rules at once, where N is the number specified after the -j switch. For example, if -j 4 was specified, there could be as many as 4 instances of the compiler at any given time, each compiling a different source.

Carbide doesn’t call make directly, only “abld” so we needed some way to get the switch passed. So we simply set the Make environment variable to “make -j N”, where N is the number of jobs to be spawned. There are seperate make calls for the different “abld build” steps. As mentioned in the previous article thos steps are ‘abld export’, ‘abld makefile’, ‘abld library’, ‘abld resource’, ‘abld target’ and ‘abld final’ respectively.

In practice we found this didn’t always work well. When building resource files in parallel we found that there could be dependency problems that would cause the build to fail. We found a similar issue with the ‘abld library’ stage. We assumed that there wouldn’t be a significant performance hit if we didn’t use the -j switch for those two stages, so for ‘abld resource’ and ‘abld library’ we don’t specify it.

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.