[fpc-devel] The future of fpmake

[Marco van de Voort]

In our previous episode, Jonas Maebe said:

(I have to be careful here, I'm not the fpmake/fppkg person, that is Joost,
these are my opinions only)

> > 1. they are mostly generated anyway. The .fpc files are the info,  
> > not the
> >   makefiles themselves.
> 
> I still prefer those Makefile.fpc files very much to the fpmake.pp  
> files. The fact that fpmake.pp files are plain Pascal code makes them  
> extremely flexible, but at the same time that also makes it much  
> harder to quickly get an overview of what they do.

Well, I can be quite short about this: me too. 

However I consider this a transitional problem only.  We are still in the
raw plumbing and discovery phase.  In time, I assume some autogeneration
helper functionality will emerge to make it at least (way) more bearable.

OTOH the trouble should not be exaggerated. I did the entire packages/
hierarchy in a few hrs spread over 2 days, and that was without any
previous fpmake experience at all, and communicating with Joost.

New packages are not added that often, and I once fpmake/fppkg gets more
mainstream, directory layout and general procedures will be more tuned to
it.

> Sticking to the Makefile.fpc format (or any other structured format) and
> then automatically generating something else from that (be it plain
> Makefiles, fpmake.pp or whatever) would make it much easier to maintain
> the actual build instructions, I think.  It would also make it less likely
> that over time some fpmake.pp will become harder and harder to read.

The trouble is that makefile.fpc does not contain all information. It is not
a closed system, and has barely enough info to build, and depends on the
autobuilding capacity of the compiler. Something that can't be used for
packaging and other features.

The fpmake is more closed. It in theory knows enough to copy files to an
isolated environment and compile, and then missing files will turn up. 

This means that there are ways to potentially validate many aspects of a
packages hierachy before a release.
 
> PS: I assume that currently there already is a way to auto-generate  
> fpmake files like this: http://svn.freepascal.org/svn/fpc/trunk/packages/univint/fpmake.pp 
>   (or did you manually derive all those dependencies, or use a quickly  
> hacked together script to parse the uses-clauses of those particular  
> units?)

IIRC there were two solutions. I first did parts with own based small
filter programs that parsed -vt output. Later Joost pointed me to some
script that was slightly better. For the rest I had a bunch of templates
ready.

The raw output was then checked and amended for OS and CPU specific cases. 
It was very semi automatic, but the simple packages (one OS, or no OS/CPU
specific data) went fairly fast, and the bulk of the work was
customization of the template.

I can't exactly remember if this also handled the include situation. Afaik
first the units were done, and later includefiles were added.

P.s. and initially there was quite some resistance against the .fpc scheme
too :-) It worked out fine, mostly due to Peter's very hard work.