[fpc-devel] The future of fpmake

[Hans-Peter Diettrich]

Darius Blaszyk schrieb:

>> fpmake's intended use is to compile your FPC code. I can see the
>> use of trying to run a testsuite, build docs and a binary zip for
>> distribution: they are all FPC related things.
>> 
>> But it is not intended as a general build system (i.e. replace make
>> or ant or rpm or deb).
> What do you mean with "general". Fpmake is a build system right? So
> why not use it also for other projects? Ok, perhaps the cdash
> functionality belongs in a different tool (although it could be in
> fpmake), but let's not limit fpmake only to FPC please. Let us (end
> users) also play with it ;)

My view on (traditional) Make:

Make is a script-driven shell, with rudimentary build-related
functionality that's missing from other shells (mainly file handling).
All other functionality sits in external tools, mainly provided by the
platform or GNU. Make has been found insufficient for certain tasks,
over time, so that another macro-processor (M4) has been added, mainly
for the determination of the capabilites of the host system and external
tools. That's the typical Unix model: when you cannot master a job in a
shell script, using existing tools, then add another tool.

In a new approach I'd provide the interpretation of existing MakeFiles,
and extend it to the specific needs and capabilities of the FPC/Lazarus
project (package...) model. Then I'd add ports of frequently used tools,
as libraries, not only for speed reasons, but also for debugging complex
build jobs.

WRT time consuming jobs, observed e.g. in building FPC itself, I'd
integrate "clean"ing of the output directories, together with means to
reduce the number of such directories, as far as possible. I'd also add
FPC as an integrated module, with a reusable file cache to prevent
excessive directory scans and loading of configs and modules.

The compiler module can be used in the Lazarus IDE as well, either as a
built-in module or as a shared library, with beforementioned ability to
share the module cache with the application. Unfortunately parallel
compilation will never become available with FPC, so that other chances
for parallel processing should be explored. As long as the build tasks
are based on input/output files (disk I/O), a shared file cache looks
like the most promising way for speeding up an build process.

When fpmake consists of dedicated modules for various tasks, these
modules can be used to build other applications, like test suite runners 
or profile editors.

Just my €0.02

DoDi