[fpc-devel] The status of fpmake ?

[Peter Vreman]

> Peter Vreman wrote:
>> If you don't have fpc installed in the default locations /usr/[local/]lib/fpc/<version> you need
>> to set FPCDIR. There is no other way to detect the location.
>
> I have it install in /opt/fpc/
> See below for details...
>
>>
>> The /etc/fpc.cfg and ~/.fpc.cfg are for the standalone compiler only and will not be used for
>> package building. fpmake and fppkg have their own configuration files where optimizer/debug
>> options will be passed to the compiler.
>
> Then why does fpmake mention fpc.cfg in it's help output.
> <snip>
> Where options is one or more of the following:
>   -h --help             This message.
>   -l --list-commands    list commands instead of actually executing them.
>   -n --nofpccfg         Compiler will not use fpc.cfg
>   -v --verbose          Be verbose when working.
> <snip>

For fpmake this is correct, but fppkg will use the --nofpccfg flag when calling fpmake.

> Attempt #3
> graemeg at graemeg:dialer$ export FPCDIR=/opt/fpc/lib/fpc/2.2.1/
>
> graemeg at graemeg:dialer$ ./fpmake build -l -v
> Warning: Source file "mydialer" not found for i386-linux
>    Compiling package MyPackage
>    Creating output dir "units/i386-linux"
>      Compiling target mydialer
>        Executing command "/opt/fpc/bin/fpc -Tlinux -FUunits/i386-linux
> -Fu/opt/fpc/lib/fpc/2.2.1/units/i386-linux/rtl "
> /opt/fpc/bin/fpc -Tlinux -FUunits/i386-linux
> -Fu/opt/fpc/lib/fpc/2.2.1/units/i386-linux/rtl
>
>
> OK, so with that looking good, I tried the build for real without the
> '-l' parameter.

Please run with --debug to get more information.


>
> Attempt #4
> graemeg at graemeg:dialer$ ./fpmake build -v
> Warning: Source file "mydialer" not found for i386-linux
>    Compiling package MyPackage
>      Compiling target mydialer
>        Executing command "/opt/fpc/bin/fpc -Tlinux -FUunits/i386-linux
> -Fu/opt/fpc/lib/fpc/2.2.1/units/i386-linux/rtl "
> Free Pascal Compiler version 2.2.1 [2008/04/21] for i386
> Copyright (c) 1993-2008 by Florian Klaempfl
> Fatal: No source file name in command line
> Fatal: Compilation aborted
> Error: /opt/fpc_2.2.1/bin/ppc386 returned an error exitcode (normal if
> you did not specify a source file to be compiled)
> The installer encountered the following error:
> External command "/opt/fpc/bin/fpc" failed with exit code 1
>

You ignored a warning. You need to specify the full source name including extension. There is no
support for default extension in fpmake, because it makes things unclear and unnecessary complex.
fpmake also needs the filename for creating a source archive.


> Makefile's was so much easier!  :)
> Or my custom method using in fpGUI:
>    fpc @extrafpc.cfg <project.pas>

fppkg and fpmake are something different. They are made to install packages and support multiple
optimizer/pic/debug configurations (this is not yet working) and targets for each package. Also it
allows you to install updated versions of packages per user. That is the reason why fppkg and
fpmake want to handle the search order of the unit dirs. A real world example is the zstream unit
that was delivered in 2.2.0 in the fcl. There have been some fixes to this unit and it is
available in the new paszlib package. When compiling fpmkunit the directory of the new paszlib and
fcl-base packages needs to be used and not the old fcl directory still available in the 2.2.0
release. These kind of issues were not solvable by the Makefile. They can be solved in
extrafpc.cfg by experienced users, but it is manual and error-prone work.

Also fppkg will take care that all installed packages are in a consistent state. E.g. updating
paszlib will trigger an implciit re-compile of all dependent (e.g. fpmkunit) packages. Extreme
example: updating the rtl means that fppkg will re-compile all packages.