I was reading the readme in FPC\utils\fppkg and saw that there should be a tool called fpmkconv that converts makefile.fpc to fpmake.pp files. I just cannot find it in the FPC sources.

Darius

Darius Blaszijk wrote

I was reading the readme in FPC\utils\fppkg and saw that there should be a tool called fpmkconv that converts makefile.fpc to fpmake.pp files. I just cannot find it in the FPC sources.

fppkg does it by itself. The functionality has been integrated. I will update the README.

Just run

fppkg convertmk Makefile.fpc

Michael.

Michael,

Thanks for explaining that, but.....

I tried to convert a sample Makefile.fpc, but I keep getting the
following error message;

fppkg convertmk Makefile.fpc

Loading global configuration from "C:\pp\bin\i386-Win32\fppkg.cfg" Generating default compiler configuration in
"C:\pp\bin\i386-Win32\fppkg\config\default"
The FPC make tool encountered the following error: Compiler returns invalid information, check if fpc -iV works

fpc -iV

2.3.1

I also tried to set the verbosity level higher, but I just cannot find out how to do that. I tried anything from -va to --verbosity=all to just -v and --verbosity. No luck.

Darius

You can't be more verbose for this. The problem is most likely that the tool cannot execute the compiler (because it does not find it).

It tries to capture the output of fpc -iVTPTO, and it expects to receive 3 words. If it does not, the error you get is displayed.

The error is in pkgoptions.pas, the function to read the output is in pkgglobals pkgglobals.pp: GetCompilerInfo; The best is to see what goes wrong there...

Michael.

You're right. I don't have a clue why, but when I remove poNoConsole for the TProcess it works. I attached a patch.

Unfortunately it still doesn't work. Fppkg cannot find the Makefile.fpc. Output below.

fppkg convertmk Makefile.fpc

Loading global configuration from "C:\pp\bin\i386-Win32\fppkg.cfg" Loading compiler configuration from
"C:\pp\bin\i386-Win32\fppkg\config\default"
Loading packages information from "C:\pp\bin\i386-Win32\fppkg\packages.xml" Loading local versions information from
"C:\pp\bin\i386-Win32\fppkg\versions-default.dat"
The FPC make tool encountered the following error: Package "Makefile.fpc" not found.

I also tried giving the full path to the makefile without success.

Darius

Ok, my fault. All you need to do is

fppkg mkconvert

It will convert the Makefile.fpc in the current directory and compiles and runs it. I just tested here, and it works fine.

Michael.

Michael Van Canneyt wrote

fppkg mkconvert

Should be "fppkg convertmk" ;)

It will convert the Makefile.fpc in the current directory and compiles and runs it. I just tested here, and it works fine.

Right, much better indeed :) But....

I got the following error message:

Unknown name/value pair in compiler section : unittargetdir Unknown name/value pair in clean section : files

Which is:
unittargetdir=./units/$(CPU_TARGET)-$(OS_TARGET)
files=$(wildcard ./units/$(CPU_TARGET)-$(OS_TARGET)/*$(OEXT)) \ $(wildcard ./units/$(CPU_TARGET)-$(OS_TARGET)/*$(PPUEXT)) \ $(wildcard ./units/$(CPU_TARGET)-$(OS_TARGET)/*$(RSTEXT))

I suspect its something about the target macro's. What is your opinion? Can we implement something for these macro's? I have an idea already but would like to pass it trough you first, if that is ok with you.

PS, what did you think about the patch?

Darius

That files line should not be necessary anymore. fpmake knows that .o/.ppu/.rst files are generated for units and needs to be clean. You only need to supply the unit names. But this part is still not 100% finished with things like implicit build units.

But as you have already found out with the fpc execution the tool is still in (stalled) development.

The poNoConsole patch is applied.

Peter

I'm with you, but fppkg keeps failing on the conversion of the macro's, which should be fixed imho. The question now is how.

But as you have already found out with the fpc execution the tool is still in (stalled) development.

Another reason why usage for non FPC projects should be supported ;) Increasing the usage will expose a lot of bugs and missing features which is good.

The poNoConsole patch is applied.

Thanks, although I still not understand why I had to remove the option.

Darius

The convertmk is only a helper. It will never support 100% conversion. The macro and function support is one of those things that will not be supported.

The main purpose for fppkg will be that all projects that want to distribute fpc units and execuatbles will be supported and produce a standard package that can be distributed from a web repository for easy downloading and installation.

>The poNoConsole patch is applied. Thanks, although I still not understand why I had to remove the option.

I also don't know, but the latest fppkg features were only tested under linux and not under windows.

Peter

I know what you mean, but if a feature is fairly simple to implement (like macros) then I see no objection to implement them. Why object? I am willing to make a patch for the feature, I was just informing on how to implement things.

I was talking about fpmake.pp files, not fppkg which is FPC dependent indeed.

Like I said, not a bad thing using it for more than FPC, because that surfaces more bugs.

Darius

Btw,

How would

./units/$(CPU_TARGET)-$(OS_TARGET)

be translated to fpmake.pp format?

Do we need to use a "Case Installer.OS of" construct or can we implement$(CPU_TARGET) and $(OS_TARGET) as functions that return a string with the current targets?
I would say just replace the macros with {$I %FPCTARGETOS%} and {$I %FPCTARGETCPU%} but how do others feel?

Darius

I think that won't work for cross compilation. It returns the targetos where fpmake s running, not the targetos you want to compile too.

Vincent

Are you shure? I mean once you have cross compiled the compiler, rtl and the lot using FPCTARGETOS or FPCTARGETCPU would yield the right information for that given compiler and rtl and the lot, not? Or do they give the actual system information? (which does not seem logical)

Darius

No, I am not sure, feel free to test and proof otherwise.

Suppose I am running on i386-linux and want to compile for i386-win32.

I compile fpmake which has {$I %FPCTARGETOS%} in its source. Suppose I compile fpmake for i386-win32, then it will contain the correct string for the unit path. Unfortunately, I cannot run that fpmake on my linux host, because it is compiled for win32.

So it is necessary to set fpctarget when compiling fpmake to the os of the host compiles the actual project using fpmake (i386-linux). In that case the unit dirs are only correct if you don't cross compile.

It is almost a proof :-)

Vincent

I can't actually cross compile here, so I will never be able to determine who's right unfortunately.

Sorry but I don't actually understand what you mean here. Is it that you mean that the following happens?

If Host = i386-linux and Target = i386-win32 then {$I %FPCTARGETOS%} = linux?
Instead of the expected {$I %FPCTARGETOS%} = win. Which is ok because the target IS i386-win32.

You never will run a "target" binary on the "host", unless the two are equal (which is normally the case). And therefore the FPC compiler info is always usable.

I'm not posing a proof here, but rather a Lemma ;)

Darius

Darius Blaszijk wrote

If Host = i386-linux and Target = i386-win32 then {$I %FPCTARGETOS %} = linux? Instead of the expected {$I %FPCTARGETOS%} = win. Which is ok because the target IS i386-win32.

Not the target for which you compile fpmake, because fpmake has to run on the host.

Jonas

Must be my ignorance regarding cross-compiling, but don't you use two compilers in that case? I mean how is a win cross-compiler going to create valid executables on a linux host?

Darius

Using a cross-assembler and cross-linker (either external or internal to the compiler). You only need a separate compiler if you compile for a different cpu platform. And even then you may also want to cross-compile the entire code on the host platform and only copy the resulting binary to the target platform.

Jonas

I believe I found a better solution to the problem. In fprepos.pp two function OSToString and CPUToString are defined.

So a string ./units/$(CPU_TARGET)-$(OS_TARGET)

would be represented as './units/' + CPUToString(Defaults.CPU) + '-' + OSToString(Defaults.OS)

Darius