The threat I described here prompts for a new build and integration system. The system should have these properties:
| - |
Ease of use
The developer must provide as little information to the system as possible and the method of providing the build system with the informations must be as natural for the developer as possible. With the current fast computers with very large memories and everything it is no longer a requirement to compell humans to accomodate to computers. |
| - |
Simplicity
I don't want to keep 50MB of binaries around just to bootstrap the system. Binaries are hard to maintain, they consume space on storage devices and create a huge obstacle against adding new platforms into the list of supported platforms. |
| - |
Treat same things in the same way and similar things similarly
The system must use the same way to describe integration of the same type of software component (program, library, data file etc). The system should use similar ways to describe integration of similar pieces of software. |
The result is called OSFIL and is takes inspiration by Borland Pascal and XML. The Borland Pascal inspired the build system language and the XML showed new ways for the build system design.
The definition of the Borland Pascal language covered not only the task of writing the algorithm in machine processable form but also the build system itself. In Pascal if you need to split source code in several modules, you need a header for each module (Borland Pascal calls it interface), where the exported routines are described and a source, where the actual code of these routines resides (implementation in Turbo Pascal nomenclature). In the other modules of the program the module is referenced via uses directive (for example uses module;). This directive allows the exported names of the referenced module to be used just as if they were defined in the referencing module.
In the C programming language there are header (*.h) and source code (*.c) files but they are a mere convention. The programmers are not forced to follow the convention so they are free for example to have header foo.h and some of the routines from it implemented in bar.c file and the rest in eggs.c file. The C standard requires only that the compiler sees prototypes (a function header with the definition missing) of the functions which are not defined in the module where they are used and a module implementing them is linked to the module using them at the link time. By contrast in Pascal you have to do all module splitting operations in a way just described or the compiler would not get you the time of day. (the Borland Pascal equivalent of the example with foo.h implemented in bar.c and eggs.c would be rejected by the Borland Pascal, actually there is no way to write such a thing in the language). This unnecessary variability prevents the C compilers and the build system itself from being able to find out themselves, which sources to compile and how to assemble the resulting binary from the pieces, so the programmer has to tell this information to the build system himself. And this is the gap that ESPM tries to fill in.
XML inspired ESPM in another way: the extendability. It is not possible to develop a fixed programming language that covers all the possible problems ranging from a simple "hello, world" program to the complete operating system source code. So, like in XML, the opposite extrem was chosen. The base of the ESPM defines only the bare necessities that allow one to bootstrap the "bare bones build system" to a full-featured, language-rich software configuration manager. These "bare bones" are the OSFIL language that covers the build system and the package management and a very simple programming language called the P Programming Language, which is so simple that its very simple compiler can be built (or linked) into the bootstrapping subsystem. However a way in the build system is provided that allows it to "learn" new languages on the fly (more specifically, as these new language compilers are integrated into the system) and then invoke their compilers as files written in them are seen. Everything that is needed to be able to do this is to write the compiler of the unknown language in a language that is already known to the build system and its compilers at the time it tries to compile the new language compiler.
Simply OSFIL is a language that allows developers to describe how to integrate programs into the underlying operating system in a standardized and easy-to-understand way. These operations are consistently defined in ESPM specification so they don't have to reinvent the wheel (pardon, integration process description) everytime the need arises.