Skip to main content

Build System

Cross-platform Build System is designed to build distributions of different operating systems for a set of target devices. The system provides independent design and quick assembly of your products in a context where you have a set of target devices with different architectures and you want that your development process become transparent and manageable.

Creating any distributive starts with the realization that the number of packages required for any modern operating system to work has long risen beyond hundreds. If you examine, for example, any popular Linux distributive, in its repository you will find several thousands, if not tens of thousands packages that were created by different people and, what is equally important, using different build automation systems. This means that the key issue is not only the amount of packages but also several build automation systems that the distributive creator has to support. Next, the question of various target device architectures that need to be supported arises and a number of other questions that multiply rapidly as you dig deeper into a seemingly easy task of building own distributive or porting Linux to some other device.

Because of this, before proceeding to develop a new product, you need to create or choose the right tool.


Build system is a set of Makefiles and utilities organized within one directory which is mounted into the source tree of the developed product.

The main purpose of the build system is automating all stages of software solution development, from arrangement of source code from third-party developers usage to publication of own deliverable distributive.

By no means we have in mind to present our work as some kind of out-of-the-box product that can be used even by unexperienced users; we assume that the user has some basic knowledge and experience. For this reason, the information here is presented in the form of articles and not as detailed instructions or manuals. We expect that, while reading the material, the reader will compare our solutions to the solutions he or she has implemented in their everyday work.

View details ≫

Package Tools

Package management tools are intended for usage in three modes.

First, they are embedded into the build system and allow automating temporary target filesystem creation on the fly, during the build process. Such filesystem can be used to test the created distributive on the target device, for example, by booting the device via NFS and debugging packages that are installed by means of the build system.

Second, these tools can be used together with the system installation utility, for example, to arrange a user interaction dialog before installing sets of packages.

And third, these tools can be used on the target machine as user tools giving the ability to install, update or remove application packages independently.

View details ≫

User's Makefile

User Makefiles must be defined in accordance with strict structuring rules. Every Makefile shall start with a list of target devices for which the packages are built. Next, lists are defined summarizing the source archives and other packages that must be present in the system before the current package can be installed, i.e. the list of packages that the package created using this Makefile depends on.

After all dependencies are specified, it is required to characterize the final package: its name, version, target architecture; in addition, a short description needs to be added that will be presented to the system's user.

And finally, a user Makefile shall define the main build targets and the package creation rules, as well as the way to populate the temporary development environment that will be used later for other packages building that depend on the current package. Of course, some parts and targets can be omitted.

View details ≫


The ability to get the application source code is essential to ensure free product distribution, but it isn't enough to call the product truly free. It is especially so for complex products where a huge amount of source code makes studying the product physically impossible, which, in turn, makes it extremely difficult for other engineers to improve the product. Even comprehensible accompanying documentation cannot assure perfect user ownership of the product. Our approach is to provide, in addition to the source code, the root ideas that were taken as the basis for the product creation. Only the knowledge about the fundamental operational principles of the system can make a user a rightful and competent owner.

In short, this section is dedicated to those who prefer owning over using.

View details ≫

Development Environment

Before the development process for a product can be started, it is essential to create the environment required to safeguard the main project goals. Apart from programming language compilers, it is important to settle such matters as own source code storage and third party archive storage.

In this article, we will describe the structure of all resources and provide some insight into the process structuring that will support quality assurance and acceptable product development speed, keeping in mind the working conditions of the engineers. Of course, by working conditions we understand the complexity and quantity of operations related to version control, release issuance and everything else that can distract the engineer from the direct product components development.

View details ≫

Build System in Practice

The best way to study some tool is to use it in practice. The introductory article only gives a simple example of building a standalone application that interacts with the C language library only and is of no interest from the perspective of deliverable packages creation.

To appreciate the system's potential, it is required to study more complicated examples and discuss the principles of multiple packages building in parallel, as well as the principles of tracking and assuring inter-package dependencies.

View details ≫


The build system's source codes are stored in an SVN repository and are available for copying.

The build system is deliverable and can be used in any projects. The user only needs to know which exactly system version is applicable to solve this or that task. The user can mount the system into the build-system directory of his/her own projects using the svn:externals mechanism by selecting the required tag or simply the HEAD of the trunk and can also keep a copy of the system in a separate directory to use with own source code tree.

View details ≫

Your message have sent successfully.

If you enter the correct return address we will be able to answer you.

Your message was not sent.

An error occurred while sending mail. Please try again later.

* fields, marked by asterisk, are obligatory for fill.