[fpc-devel] (Re)compiling FPC or is there something like fpc.bpg?

[Joost van der Sluis]

On Sat, 2010-07-24 at 14:40 +0300, Adem wrote:
> On 2010-07-24 1:28 PM, Graeme Geldenhuys wrote:
> > This is easy to do with a few IFDEF lines...
> >
> > {$IFDEF APROGRAM}
> >> {...}
> > {$ENDIF}
> > {$IFDEF APROGRAM}
> >>   {...}
> > {$ENDIF}
> >
> > Now if APROGRAM is defined, they act as self-contained programs. If
> > not, they act as include files and can be combined.
> There are 115 'fpmake.pp' files in the trunk --(or more, because I 
> haven't yet been able to get a full local copy of the FPC).
> 
> Even then, I have no guarantees that those files are up-to-date.

Problem is that we are in a very slow conversion from fpcmake to fpmake.
At this moment we use fpmake to build the releases, to the Makefiles.fpc
are guaranteed to be up to date. But in the far future we will use
fpmake for some parts. Then you'll know for sure that the fpmake files
are up-to-date.

> While I am prepared to do the manual work, I don't know enough about 
> FPC's internals to decide what should be in those files.
> 
> Meaning, I would need a lot of hand holding along the way.
> 
> Boy, I could kill for a 'makefile' parser...

Rofl. We use a makefile-generator, which you want to parse again? Just
use the primary source.

Using fpcmake, the Makefile.fpc's are converted into the Makefile's.
With fpmake, programs are directly compiled (no need for make).

> >> in a file called, say, 'fpmake.pp.inc'.
> > FPC doesn't care about the file extension, so you can name them all
> > *.pas (even if they are include files - no APROGRAM define exists).
> Actually, ATM, I am inclined towards generating an XML file which holds 
> all the necessary info.
> 
> Any comments on that?

fpmake can generate an xml file which contains a lot of info already.

Joost.