Difference between revisions of "FPMake revamp"

From Free Pascal wiki
Jump to navigationJump to search
(Created page with "{{FPmake}} 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 id...")
 
Line 9: Line 9:
 
=== 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 onderlying build-systems show that enforcing one design is easier, and in the long term also more feasible.
 
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 onderlying 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)

Revision as of 20:08, 21 July 2022

Template:FPmake

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.

Basic 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 onderlying 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)