Difference between revisions of "FPMake revamp"
| Line 3: | Line 3: | ||
[[FPMake]] is a build-system for Pascal code specifically. It can use a make-over, though. | [[FPMake]] is a build-system for Pascal code specifically. It can use a make-over, though. | ||
| − | This document is a place to gather basic design-principles and other ideas for the new version. It is all work-in-progress and input is very welcome. | + | This document is a place to gather basic design-principles and other ideas for the new version. It is all work-in-progress and any input is very welcome. |
== Basic design principles == | == Basic design principles == | ||
=== Keep it simple === | === Keep it simple === | ||
| − | One of the things that makes fpmake so complex, is that it tries to do everything that it's predecessors also did. And tries to accommodate all kind of different package-designs as possible. The new version will not do this any more. Other package-managers (yarn, npm) and their | + | |
| + | One of the things that makes fpmake so complex, is that it tries to do everything that it's predecessors also did. And tries to accommodate all kind of different package-designs as possible. The new version will not do this any more. Other package-managers (yarn, npm) and their underlying build-systems show that enforcing one design is easier, and in the long term also more feasible. | ||
This means: | This means: | ||
| Line 16: | Line 17: | ||
* Options to do all kind of fancy stuff, like copying files around, calling external applications, zipping files are removed or limited. So they are not tempted to create their own packages-layouts. | * Options to do all kind of fancy stuff, like copying files around, calling external applications, zipping files are removed or limited. So they are not tempted to create their own packages-layouts. | ||
* etc | * etc | ||
| + | |||
| + | === First define the packages, process them later === | ||
| + | |||
| + | The packages are defined and configured first. In a later stage they are being processed (build, installed, etc) | ||
| + | |||
| + | This leads to a clear design, in which a package-developer knows what is possible and what not. It also makes it easier to create external packages in a repository. Due to the declarative process, it is easier to collect a packages properties inside a declaration-file. (On which the central repository can base it's information) | ||
=== Clear separation of responsibilities === | === Clear separation of responsibilities === | ||
| + | |||
| + | In fpmkunit their was clearly an attempt to separate different responsibilities. But the original ideas got lost and it was not clear anymore which class should do what. | ||
| + | |||
| + | In the new setup the separation should be crystal clear again, and is as much as possible enforced bij using (corba) interfaces for interfacing. | ||
=== Separation between build, target and host === | === Separation between build, target and host === | ||
The original fpmake only dealt with the '''target'' (cpu, abi and operating system) and only implicitly the '''build''' system. Now fpmake differentiates between the '''build'''-system (on which the system is running), the '''host''' system (on which the created compiler is running) and the '''target''' system, for which the compiler will create code. | The original fpmake only dealt with the '''target'' (cpu, abi and operating system) and only implicitly the '''build''' system. Now fpmake differentiates between the '''build'''-system (on which the system is running), the '''host''' system (on which the created compiler is running) and the '''target''' system, for which the compiler will create code. | ||
| + | |||
| + | === Extensibility === | ||
| + | |||
| + | Extensibility goes into two ways: | ||
| + | |||
| + | # Extending the ability to define packages. For example: define packages based on the Lazarus .lpi-format. | ||
| + | # Extend the actual installer. In `fpmkunit` the support of threading and other features that are not available are enabled using defines. The idea is that the new system uses another approach. To make it possible to select other 'runners'. Which each can offer different features, and support different platforms. | ||
| + | |||
| + | == Basic design == | ||
| + | |||
| + | This is not a full documentation of fpmake. Only the basic building-blocks are described here. | ||
| + | |||
| + | === Structures === | ||
| + | |||
| + | Functionality is split into a few units. | ||
| + | |||
| + | ==== Basic units ==== | ||
| + | |||
| + | Can be used throughout all parts of fpmake. Note that a lot of these are interfaces. The actual implementation might differ. Depending on a particular package, or actual runner. (See [[#Extensibility]]) | ||
| + | |||
| + | ; fpmku | ||
| + | : Basic definitions and functionality which are used throughout all parts of fpmake. | ||
| + | ::; IStaticSettings | ||
| + | :: Holds all the settings which are independent of the individual packages. For each run of fpmake they are constant and the same for all packages. Such as the used ''compiler'', ''host''-, 'target''- and ''build''-architectures. | ||
| + | ::; IDynamicSettings | ||
| + | :: Holds all the settings which can differ between packages. Like the unit-search paths which depends on a package dependencies. Of compiler-options. | ||
| + | ::; IPackage | ||
| + | :: The base interface for a package | ||
| + | ::; IPackageHelper | ||
| + | :: A helper class with lots of routines that makes live easier. Like logging, error-handling and such. | ||
| + | |||
| + | ==== Basic package units ==== | ||
| + | |||
| + | Units which are used by package-definitions. Note that every package determines on it's own how the package is actually defined. As long as it implements the ''IPackage'' interface. | ||
| + | |||
| + | ; fpmkpck | ||
| + | : Base classes to define a package. A package '''may''' use this unit to define a package. But other implementations are also possible. | ||
| + | ::; TBasicPackage = class(IPackage) | ||
| + | :: | ||
| + | ::; TPackage = class(TBasicPackage) | ||
| + | :: | ||
| + | ::; TUnitTarget = class(IGoal) | ||
Revision as of 00:29, 21 August 2022
FPMake is a build-system for Pascal code specifically. It can use a make-over, though.
This document is a place to gather basic design-principles and other ideas for the new version. It is all work-in-progress and any input is very welcome.
Basic design principles
Keep it simple
One of the things that makes fpmake so complex, is that it tries to do everything that it's predecessors also did. And tries to accommodate all kind of different package-designs as possible. The new version will not do this any more. Other package-managers (yarn, npm) and their underlying build-systems show that enforcing one design is easier, and in the long term also more feasible.
This means:
- No functionality to adapt the location of .ppu, .o, .frs, binaries, help-files, tests or any other files. (The UnitInstallDir, UnitConfigFilesInstallDir etc)
- No need anymore for macro's ($(target) and such)
- Options to do all kind of fancy stuff, like copying files around, calling external applications, zipping files are removed or limited. So they are not tempted to create their own packages-layouts.
- etc
First define the packages, process them later
The packages are defined and configured first. In a later stage they are being processed (build, installed, etc)
This leads to a clear design, in which a package-developer knows what is possible and what not. It also makes it easier to create external packages in a repository. Due to the declarative process, it is easier to collect a packages properties inside a declaration-file. (On which the central repository can base it's information)
Clear separation of responsibilities
In fpmkunit their was clearly an attempt to separate different responsibilities. But the original ideas got lost and it was not clear anymore which class should do what.
In the new setup the separation should be crystal clear again, and is as much as possible enforced bij using (corba) interfaces for interfacing.
Separation between build, target and host
The original fpmake only dealt with the target (cpu, abi and operating system) and only implicitly the build' system. Now fpmake differentiates between the build-system (on which the system is running), the host system (on which the created compiler is running) and the target system, for which the compiler will create code.
Extensibility
Extensibility goes into two ways:
- Extending the ability to define packages. For example: define packages based on the Lazarus .lpi-format.
- Extend the actual installer. In `fpmkunit` the support of threading and other features that are not available are enabled using defines. The idea is that the new system uses another approach. To make it possible to select other 'runners'. Which each can offer different features, and support different platforms.
Basic design
This is not a full documentation of fpmake. Only the basic building-blocks are described here.
Structures
Functionality is split into a few units.
Basic units
Can be used throughout all parts of fpmake. Note that a lot of these are interfaces. The actual implementation might differ. Depending on a particular package, or actual runner. (See #Extensibility)
- fpmku
- Basic definitions and functionality which are used throughout all parts of fpmake.
- IStaticSettings
- Holds all the settings which are independent of the individual packages. For each run of fpmake they are constant and the same for all packages. Such as the used compiler, host-, 'target- and build-architectures.
- IDynamicSettings
- Holds all the settings which can differ between packages. Like the unit-search paths which depends on a package dependencies. Of compiler-options.
- IPackage
- The base interface for a package
- IPackageHelper
- A helper class with lots of routines that makes live easier. Like logging, error-handling and such.
Basic package units
Units which are used by package-definitions. Note that every package determines on it's own how the package is actually defined. As long as it implements the IPackage interface.
- fpmkpck
- Base classes to define a package. A package may use this unit to define a package. But other implementations are also possible.
- TBasicPackage = class(IPackage)
-
- TPackage = class(TBasicPackage)
-
- TUnitTarget = class(IGoal)
