[Please bear with me while I am trying to formulate this question; it is a tough one to do succinctly]

If I am not mistaken, a version X of FPC is guaranteed to be compilable with version (X - 1).

If that is so, I am assuming, one would not have to 'make' version X; meaning you could compile version X with the binaries form (X -1) if you had something like fpc.bpg (i.e. project group).

The reason I am aiming for fpc.bpg is to avoid the problem of 'no spaces in file paths' problem.

Even though 'fpc.bpg' does not exist, it seems all the information necessary to genereate one is there in the numerous 'fpmake.pp' units in the 'source' directory.

Now the questions:

1) Does the 'fpmake.pp's contain all necessary information to generate a 'fpc.bpg'?

2) If yes, would it be possible to use this newly generated 'fpc.bpg' to compile a new version of FPC without worrying about spaces in paths? [I.e. does 'make' perform any 'deus ex machina' tricks that fpc.exe itself cannot?]

3) If yes, how much of the previous version's 'bin' folder would have to be there to compile 'fpc.bpg'?
[There are some 69 binaries under 'bin', totalling some 7.5 MB; I'd like to cut it down to a bare minimum if possible.]

There is already a fpc.lpi which can correctly build and debug the compiler using Lazarus as the IDE.

There is nothing like that for the RTL and Packages AFAIK, but one could possibly create that, setting a call to the makefiles to build it.

I think that fpmake.pp is exactly what you want. Only it doesn't work fully yet.

If fpmake works, we don't need make anymore.

Joost.

In our previous episode, Joost van der Sluis said:

It is not, since it requires an installed RTL + fpmkunit to create the first fpmake. This is the bit handled by the still to be created bootstrap scripts.

I'm using fpcmake and make for my project and it works fine since years. So whatever you use to build the compiler, please dont drop fpcmake :-) Thanks!

Stefan

What I am aiming is to, first, get the information in each 'fpmake.pp' file into one single 'Installer' object.

Then, from that object, I'll try to generate a project file to be compiled under Lazarus.

It looks doable, except that, each 'fpmake.pp' file is a project with information such as below.

program  fpmake;
   uses  fpmkunit;
   Var
     P: TPackage;
     T: TTarget;
   begin
     With Installerdo
     begin
       P := AddPackage('my-nice-program');
       P.OSes  :=[win32,openbsd,netbsd,freebsd,darwin,linux];
       T := P.Targets.AddUnit('myunit');
       T.ResourceStrings  :=True;
       T := P.Targets.AddUnit('myprogram');
       T.Dependencies.Add('myunit');
       Run;
     end;
   end.

This is, unfortunately, less than usable for my purposes.

What I would like is something like this:

With Installerdo
begin
   P := AddPackage('my-nice-program');
   P.OSes  :=[win32,openbsd,netbsd,freebsd,darwin,linux];
   T := P.Targets.AddUnit('myunit');
   T.ResourceStrings  :=True;
   T := P.Targets.AddUnit('myprogram');
   T.Dependencies.Add('myunit');
   Run;
end;

in a file called, say, 'fpmake.pp.inc'.

Then, I could simply combine them into a single unit.

Obviously, a little more work is involved but this is the gist of it.

Now, what I'd like to know is what generates those 'fpmake.pp' files, so that I might take a shot altering it to generate 'fpmake.pp.inc' files the way I wanted.

In our previous episode, Adem said:

Now, what I'd like to know is what generates those 'fpmake.pp' files, so that I might take a shot altering it to generate 'fpmake.pp.inc' files the way I wanted.

They are not generated.

Oppps...

I suppose I am not to assume they are up-to-date etither..

if so, this is going to be fun.

Let me start again.

When I look at 'Makefile' files, I see this as the first line "Don't edit, this file is generated by FPCMake Version 2.0.0 [2009/12/31]"

It implies that 'fpcmake.exe' can generate those 'Makefile's.

Which brings me to next questions:

1) Where does fpcmake get that information?
2) Where is the source of fpcmake?

Hi!

Adem wrote

1) Where does fpcmake get that information?

The base/generic information is from the fpcmake.ini in fpcmake's source directory (see below). The packages specific parts are from the Makefile.fpc files.

2) Where is the source of fpcmake?

You can find it in $FPCSRC\utils\fpcm\

Btw: the fpmake.pp files are not used by fpcmake, but by fppkg (see $FPCSRC\utils\fpcm)

Regards,
Sven

2010/7/23 Adem :

What I am aiming is to, first, get the information in each 'fpmake.pp' file into one single 'Installer' object.

This is easy to do with a few IFDEF lines...

{$IFDEF APROGRAM}

{$ENDIF}

{$IFDEF APROGRAM}

 end.

{$ENDIF}

Now if APROGRAM is defined, they act as self-contained programs. If not, they act as include files and can be combined.

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).

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.

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...

> 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?

I don't know what you want, but fpmake *is* an installer. Run ./fpmake --install. (Or better fppkg --install) If you want to use the fpmake files as an include-file, look how the same thing is done in the packages-directory of fpc.

Joost

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.

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).

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

Joost.

Joost van der Sluis wrote

I don't know what you want,

Wel... it all started here [
].

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).

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.

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

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..

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

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.

> 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.

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?

If you don't use the installer but build lazarus yourself from the sources, both 32 an 64 bit version of lazarus can run side by side. No problems with that. (ok, you need to rename lazarus.exe to lazarus32.exe / lazarus64.exe)

Marc

I wouldn't like to come across as one looking a gift horse in the mouth [
http://www.phrases.org.uk/meanings/dont-look-a-gift-horse-in-the-mouth.html ], but I'd like it to be made point-and-click operation :)

I am prepared to contribute to that end, but doing all that manual installation is a chore.

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.

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?

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.

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

I think using fpmake --manifest.

See here for more information:
http://wiki.freepascal.org/fppkg

Joost.