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

Joost van der Sluis joost at cnoc.nl
Tue Jul 27 21:16:28 CEST 2010

On Tue, 2010-07-27 at 14:07 +0300, Adem wrote:
> On 2010-07-27 1:10 PM, Joost van der Sluis wrote:
> > I don't know what you want,
> Wel... it all started here [ 
> http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg17986.html ].
> In short, I was trying to test/benchmark a FPC/Lazarus generated exe 
> against one with Delphi, but I kept having to uninstall 32-bit 
> FPC/Lazarus when I needed to produce  a 64-bit FPC/Lazarus exe.
> IOW, both versions wouldn't coexist under the same OS (Windows 7).

That's most certainly not true. But the best way to do this is to
install the 32-bit lazarus and the 64-bit cross-compile add-on. Then you
can make 32bit and 64bit applications without any difficulties.

When you install both versions, make sure that the fpc-files are
installed into the same directory (it will add i386-win and x86_64-win
folders). Or else you have to know how you must adapt the fpc.cfg file.
(And Lazarus configuration) 

> What's more, I found that, when you uninstalled FPC/Lazarus, it didn't 
> clean up after itself --leaving the whole folder structure and other 
> esiduals for manual removal.

That's a bug, offcourse. Which installer did you use? And which files
were left over?

> Similarly, I couldn't find a simple enough way of using different 
> versions of FPC under different versions of Lazarus.

Also not that difficult, but you need to know what you're doing. And the
difficult part is that you have to recompile the lcl each time you
switch fpc-version. And offcourse the source-path for code completion
and such. I don't think that this is a setup which is used a lot. And I
won't recomend it. 

> Anyway, as I listed out ideas of how it should be, Mattias kindly asked 
> me to take the matter into my own hands <g> by saying "Feel free to do so."
> Ever since, I am trying to find a way to compile/'make' FPC from sources 
> and make the installation compatible with spaces in paths..

That's a little bit tricky of Mattias. Maybe you could have guessed that
the reason why this problem isn't solved is that it is difficult to
solve. I don't think it's an easy task for you to try this. Otoh, if we
want to have this fixed, someone has to start with this.

Largest problem are the tools which are from other parties. (ie: the
gnu-utils like ld, as and make) So the goal is to get rid of them. The
introduction of fpmake is part of that process. But it's not that easy.

First step for you would be to see when it goes wrong with spaces in
filenames. I think the last place it really went wrong was the
resource-compiler. But with the upcoming fpc 2.4.2 and new Lazarus
version we don't use the gcc-resource compiler anymore. Maybe that that
solves all (difficult) problems. I'm not sure...

> Obviously, 'make' couldn't handle paths with spaces, so I turned to 
> compiling FPC with an immediately previous version of FPC.

Is that so? Did you test that?

> Someone, then, suggested 'fpmake' --or, rather the 'fpmake.pp' files it 
> uses.
> Well.. This is where I am stuck:
> Not only are those 'fpmake.pp' files not up-to-date, they are also 
> individual programs with {$IFDEF}s and {$INCLUDE}s etc..
> IOW, not very conducive to extracting the information I need to compile 
> FPC and install to folder structure I want it.
> {your next post is below}
> > 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.
> Why only 'some parts', why not the whole thing? Just curious.

Because that would result in a reversed chicken and egg problem. You
need to have fpmake on your system to be able to install the compiler.
But to build the compiler you need fpmake. This is solveable using
cross-compilers, and also holds for the compiler itself but complicates
things a lot. 

So we will always need some scripts to do some work outside fpmake. And
it is also that we don't want to rush this. If the build-system of the
compiler itself fails, we'll get a lot of problems with users trying to
compile everything by theirselves.

> >> 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.
> Desperate times..
> I checked the whole Internet, and even though there a plenty of people 
> complaining about the lack of support for spaces in paths, it appears 
> not a single soul has stepped forward to remedy the situation.

Because it's difficult, and no-one really cares: simply don't use spaces
in your *development* environment is the easiest fix.

> Nor is there a usable 'makefile' parser in any language that I could locate.
> > Using fpcmake, the Makefile.fpc's are converted into the Makefile's.
> > With fpmake, programs are directly compiled (no need for make).
> I have avoided even looking at makefile contents all my life, so I am 
> less than a noob on that, but from what I can tell, fpcmake uses a 
> template makefile and substitutes/replaces certain portions in that 
> template.
> IOW, it is harder to understand (for me) what fpcmake is doing than 
> understanding what the stuff in a makefile means.
> > fpmake can generate an xml file which contains a lot of info already.
> Great, I might be getting somewhere.
> How do I get fpmake to produce that xml file?

I think using fpmake --manifest.

See here for more information:


More information about the fpc-devel mailing list