Re: Delphi language support in CMake build system

On 2008-10-20, eric.lemings@xxxxxxxxx <eric@xxxxxxxxxxx> wrote:
...

If you want a non trivial example, see how the main FPC/Lazarus trees work
with gmake. (and be quick, since gmake use will be eliminated soon I hope)

Eliminated or replaced? If replaced, with what?

Both, an external dependancy eliminated and replaced as buildsystem by
something of our own.

Note that currently we already operate with a moderately complex
template+generator system, it was not "pure" gmake.

A makefile

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/Makefile?view=markup

and the template for this file:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/Makefile.fpc?view=markup


The new tool is more specialized for the FPC project (and related projects)
only, and turns away the whole concept of dependancies as a script/data to
be reintepreted at each build.

It simply uses a pascal source in which, using objects, you specify a list
of files to build, includepaths, dependancies etc:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-base/fpmake.pp?view=markup

)

The datatree thus built can be used to build/clean etc, and the same
data-tree can also used for packaging/managing an apt-get like packaging
system (based on source distribution rather than binaries though, maybe more
portage like)

The nice part of course being the considerable programming freedom in the
build system, fitness for its specific purpose, and the "one language to run
the project" principle.

That latter aspect is maybe the most important one, instead of contributing
to the current habit of everybody adding scripts in his pet scriptlanguage
to the project, simply use programs in the main language. It also avoids the
pitfall of mapping everything on a not suitable C build system.

The current build system might also be faster, but I doubt (gmake) eats that
much time of the current build process to make a dent, so that is not a real
design criterium.

We hope that more of the devels and intermediate users get involved in
maintaining the build system, instead of the current few that know their
(grudging) way around the makefiles, and worse, the main template.

In the above example you can also see the "allpackages" hack, which is a
simple define used for a different build mode where the entire tree of
source is scanned for these files and they are baked into a single binary
that in one execution builds the whole system.

This single binary has then an intimate knowledge of all files in the entire
tree including their OS dependancies, but of course has to be build after a
non trivial update. (there is some leeway for little changes, since the
autobuilder takes care of a lot already)

The entire system can be bootstrapped using one or two commands using one
single (static) compiler for bootstrap, through
rtl-compiler-buildsystem-packages-ides, without the need for specialized
bootstrap compilers and libraries.

It's all still experimental (as in not used in releases) but already working
and pretty much feature complete. Actually the build part is pretty much
working, the apt-get like stuff (source packaging) needs more work, as does
validating the proper building of all trees, including cross-aspects etc.

I personally like the build system, but have a few doubts about the apt-get
like distribution system. While nice, I've a feeling it will be more work
then regular releases, and it is hard to get enough manpower (specially on
the rarer platforms) for that now.

I also don't know yet if some equivalent of -j is already possible. Note
that also currently with gmake we only use -j on whole directory level, so
it is a simpler case to replace. Within a directory, autobuilding is way
more worthwhile. (pretty much not even reloads precompiled state, let alone
header reparsing).

Probably makefiles for the base RTL-compiler system will be kept for porting
purposes.
.