The OSFIL is split into two parts:
| - |
Skeletal OSFIL
This is the portion of the OSFIL language that must be supported by the OSFIL processor directly. It is composed of the language that is used to describe software packages and of a programming language called P Programming Language, which is a derivative of the C/C++ programming languages. This composition makes the skeletal OSFIL powerfull enough to be able to write a program to bootstrap a full blown operating system so only the bare OSFIL processor is the only binary needed to bootstrap the system while simple enough that the bare OSFIL processor binary is not very large (a few hundreth of kilobytes at most). |
| - |
Muscle OSFIL
The "muscles" of the OSFIL are other programming languages that are attached to the skeletal OSFIL. Once a programming language is attached to the OSFIL, the programming language becomes an integral part of OSFIL, just like the P Programming Language is. No ad-hoc ways are needed for this integration, a standard way in the skeletal OSFIL is provided for that purpose instead. These "muscles" are not supported by the bare OSFIL processor, a package containing the support for a particular "muscle" must be integrated into the OSFIL processor before that "muscle" can be used. |
The idea behind this is that when building the entire binary version of the OSHS distribution, you start with a single small binary (the OSFIL processor) which knows only the skeletal OSFIL and a huge amount of source codes. The OSFIL processor then must automatically
There are other ideas to be integrated into OSFIL:
| - |
FreePascal units
This idea was invented for the Turbo Pascal programming language, which is now supported by the FreePascal compiler. This idea is to split any unit (a nickname for a module) into two sections called interface and implementation section. When the unit is used, the user of the unit specifies only the name of the used unit in a special language directive (so-called uses clause in Pascal nomenclature) and the compiler makes everything declared in the interface section of the used unit to be accessible like it was declared in the user of the unit. This idea almost removes the need for makefiles since by traversing the uses clauses the compiler can determine what belongs to a particular program (only the name of the file containing the entry point to the program needs to be specified to the compiler).
|
| - |
USE flags
USE flags are invented by the package manager of the Gentoo Linux distribution. The idea is very simple: by stating special keyword in a directive in a configuration file (which happens to be USE, therefore the name) you can choose which optional support you want. The building system then looks at the content of this directive when it has to decide what to enable and what not. |
| - |
Program and library unification
This idea is taken from libtool and expanded. libtool says that libraries are merely programs with multiple entry points. OSFIL extends this concept by introducing the term of executable entry point which is simply only another name for the function main() well known from the C programming language, and by blurring the boundary between the programs and the libraries away by calling both of them binaries. A binary that contains the executable entry point can be invoked by its name in the shell, thus is a program; a binary without one cannot, thus is a library. However a binary that contains the executable entry point can also contain other entry points which are not accessible from the shell but can be accessed by other binaries by linking against it, therefore it is perfectly possible to link other binaries against what is called a program. The executable entry point itself can also be made public and then accessed by other binaries by linking against the binary containing it, thus bypassing the overhead of asking the shell to execute the program.
|
Software description language is what is spoken in the .DOP (Description Of Package) files. Each package must have exactly one .DOP file and this file is where the package building starts. The .DOP file contains informations about the package to be displayed for the user and the informations used by the building system to decide how to build the package. It is the first file being searched for and read by the build system.
The closest relative to the .DOP file is the RPM spec file.
For more info see ???
Programming languages are what is used to tell the computer "what to do". There are lots of programming languages out there but only a few of them are popular.
The idea of an OSFIL modulr is a combination of the FreePascal unit concept with the concept of the C header files.
FreePascal units are modules that contain objects (code or data) accessible to other modules (the module that contains the entry point of the program is not an unit and an unit cannot contain an entry point to a program). They are splitted into two parts, a publicly visible interface section which describes what in the unit can be used from outside and a publicly invisible implementation section which contains the rest of the unit. Other modules use what is known as uses clause to bring the content of the interface section of an unit to their scope of visibility. The compiler then needs to know only the module where the entry point of the program is located; all other modules belonging to a program are found by traversing the uses clauses found in the modules.
In OSFIL this concept is combined with the C idea of the header files to produce an idea of having two files for a module in a program: the first one called header file or interface file contains the interface section of the module and the second one called source code file or implementation file contains the implementation section of the module. The OSFIL requires that both files must have the same name which also happens to be the name of the module itself. The two files are distinguished by their extensions.
FreePascal units can contain code that is automatically called at program startup and/or termination when the program uses that very unit.
In OSFIL this idea is transformed into an idea of automatically initialized objects. Each declared object (a procedure or a variable) can have initializers attached to it, no matter whether it is public or private. Even the initializers themselves can have another initializers attached to them. An initializer is a parameterless procedure that performs some actions to make sure the initializee is working correctly or contains a correct value. The compiler then can ensure that at the program startup the initializers are called in the correct order, only the needed initalizers are called and each such initializer is called exactly once.
Programming languages are identified by the extensions of the source code files. These extensions also tell the compiler whether the file is a header file or a source code file. The OSFIL processor uses these informations to determine which compiler to call on the file and what modules are used by a particular program (so it can tell the linker what to link together).