[Lazarus] How to use two different versions of FPC

[Gabor Boros via Lazarus]

Hi All,

My main development toolset is FPC 3.0.4 and Lazarus fixes_1_8.
Sometimes I try some things with Lazarus trunk also. It is easy.
But now build up a new development machine from scratch with RHEL 7.5 on
it and try to utilize FPC trunk too (with Lazarus trunk). I use
"--primary-config-path" option always, so Lazarus config placement is
not a problem. But the two FPC versions coexist. I found a solution from
2012 on the forum (see the link below). Is BigChimp's suggestion (1.-6.)
a good starting point nowadays or something changed meanwhile in this
topic. I will build everything (Lazarus fixes_1_8 and trunk, FPC trunk)
from source except the actual stable FPC (now 3.0.4).

https://forum.lazarus.freepascal.org/index.php/topic,15716.msg85158.html#msg85158

Gabor
--

[shoKwave via Lazarus]

Is BigChimp's suggestion (1.-6.) a good starting point nowadays or
something changed meanwhile in this topic. I will build everything
(Lazarus fixes_1_8 and trunk, FPC trunk) from source except the actual
stable FPC (now 3.0.4).
https://forum.lazarus.freepascal.org/index.php/topic,15716.msg85158.html#msg85158

Hi Gabor,

it's a good starting point but I have some corrections.

* Install systemwide FPC and whatever primary Lazarus install you want
* Get another FPC, e.g. from SVN, make all, make install under e.g.
~/fpcdev
* make softlink from ~/fpcdev/lib/fpc/<version>/ppcbinary to ~/fpcdev/bin
* Generate an fpc.cfg in ~/fpcdev/lib/fpc/etc directory using fpcmkcfg
* Get/compile another Lazarus using make
FPC=~/fpcdev/whereverbin/ppcbinary so Laz gets compiled with the
right FPC
* Run secondary Lazarus with --primary-config path set to a new
directory, e.g. ~/lazarusdev/
* Set up secondary Lazarus Options/Paths, specifying FPC directory as
~/fpcdev/wherever...

#3 is new. The link is not generated by make so you'll have to create it
by yourself.

#4 is slightly different. On Linux and MacOS fpc expects the fpc.cfg to
be in the relative path "../etc/fpc.cfg"  (see
https://linux.die.net/man/5/fpc.cfg).

Hope this helps.

Ingo

--

[Anthony Walter via Lazarus]

I am not sure if this will help, but I place this script as "setup" in any
fpc directory:

#!/bin/bash

if [ -z ${OLDPATH+x} ]; then
OLDPATH=$PATH
else
PATH=$OLDPATH
fi

BASE="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
export PPC_CONFIG_PATH=$BASE/bin
rm $PPC_CONFIG_PATH/fpc.cfg > /dev/null 2>&1
$PPC_CONFIG_PATH/fpcmkcfg -d basepath=$BASE/lib/fpc/\$FPCVERSION -o
$PPC_CONFIG_PATH/fpc.cfg
export PATH=$PPC_CONFIG_PATH:$OLDPATH

Then when I want to change compilers, I go to the fpc folder with the
version I want to use and execute:

. ./setup

This sources the script setup, and changes the fpc version. Example:

***@debian: fpc
*bash: fpc: command not found*
***@debian: cd $HOME/Development/FreePascal/fpc-trunk
***@debian: . ./setup
***@debian: fpc -iV
*3.1.1*
***@debian: cd $HOME/Development/FreePascal/fpc-3.0.0
***@debian: . ./setup
***@debian: fpc -iV
*3.0.0*

What this script does is save the old path, put the bin folder of fpc in
the path, set the PPC_CONFIG_PATH variable, and generate a new bin/fpc.cfg.
You can then have as many fpc compiler versions as will fit on disk, and
change compilers easily.

So in summary, copy my script above to each fpc folder, name it setup,
chmod +x setup, and . ./setup to change to a specific compiler.

[Joost van der Sluis via Lazarus]

Attached snapshot is work in progress

Sorry, but I don't think this is an improvement. For new users this
make it a plugin.

This is a plugin.

In that case: nothing said. Nice work! ;)

Joost.
--

[Michael Van Canneyt via Lazarus]

Oh, you may do so. But it is unnecessary and confusing in the fpc-case.
Off-course you can configure Lazarus to use fpc.sh. But what do you do
in a terminal? Wouldn't it be easier to just call 'fpc_304' and
'fpc_trunk'? Or /path/to/compiler/versiona/fpc and
/path/to/compiler/versionb/fpc?
Believe me when I say that most fpc-developers have really difficult
setups, which a lot of different versions of fpc installed. And they do
not use scripts like fpcup. They also don't type magically looking
command lines. They use just the features already build into the compiler.

Indeed. I have 13 versions installed, dating back to version 2.0.0
No tricks needed.

Michael.
--

[Mark Morgan Lloyd via Lazarus]

Op 08-05-18 om 13:46 schreef Giuliano Colla via Lazarus:> E.G. you may
have a full tree (fpc+Lazarus) in ~/development/ another > one in
~/production and a third one in ~/experiments. The main trick, as > far
as fpc is concerned, is to have as fpc executable an fpc.sh (a name >
which is accepted by Lazarus) which sets up whatever is needed. This is

a sample of fpc.sh:> >> #!/bin/sh # This script starts the fpc

compiler installed by fpcup # >> and ignores any system-wide fpc.cfg
files # Note: maintained by fpcup; >> do not edit directly, your edits
will be lost. >> /home/colla/development/fpc/bin/x86_64-linux/fpc -n >>
@/home/colla/development/fpc/bin/x86_64-linux/fpc.cfg "$@" That's more a
hack then a solution, and the real solution is simple and also works
outside Lazarus: place the fpc.cfg in ~/experiments/etc,
~/development/etc etc, as already suggested by Ingo. Or, even better,
just alongside the compiler-executable. You can call 'fpc -va' to check
which configuration file is used.

On Linux and Solaris I have a /usr/local/bin/fpc.d directory containing
multiple versions. In /usr/local/bin I basically have

fpc
fpc.d
fpcres
ppcx64 -> ppcx64-3.0.2
ppcx64-2.6.4 -> /usr/local/lib/fpc/2.6.4/ppcx64
ppcx64-3.0.0 -> /usr/local/lib/fpc/3.0.0/ppcx64

It works well except for building FPC itself when I have to modify the
ppcx64 symlink, and there were problems with trunk at some point when it
ignored instruction to install into e.g. fpc.d/2.7.1

[patspiper via Lazarus]

Post by Gabor Boros via Lazarus
My main development toolset is FPC 3.0.4 and Lazarus fixes_1_8.
Sometimes I try some things with Lazarus trunk also. It is easy.
But now build up a new development machine from scratch with RHEL 7.5
on it and try to utilize FPC trunk too (with Lazarus trunk). I use
"--primary-config-path" option always, so Lazarus config placement is
not a problem. But the two FPC versions coexist. I found a solution
from 2012 on the forum (see the link below). Is BigChimp's suggestion
(1.-6.) a good starting point nowadays or something changed meanwhile
in this topic. I will build everything (Lazarus fixes_1_8 and trunk,
FPC trunk) from source except the actual stable FPC (now 3.0.4).

Attached snapshot is work in progress

Stephano

[patspiper via Lazarus]

En Fri, 11 May 2018 08:40:28 -0500, patspiper via Lazarus

Attached snapshot is work in progress

Sorry, but I don't think this is an improvement. For new users this
looks like a nightmare. It should be hidden, at least, imho. Or
better: make it a plugin.

As Mattias has pointed out, it is a plugin (IDE package), and
definitely not for the faint of heart.
Once one creates a standardized folder hierarchy for the different
fpc versions, it becomes a matter of a few clicks to switch versions.
Stephano

An easy way to switch the compiler is nice, but I think that it would
be nicer if it could be organized in compiler profiles so you can have
compilers with the same version but with or without debug info or
compiled with different options. Then a compiler profile could be
specified/selected by build mode so it could be stored in the session
or the project file. :)

Compiler profiles that can be selected in project options as well as in
Tools/Options (for IDE rebuilding) would be very nice indeed.

Currently I am investigating how to enable fpc debug units in a suitable
way.

Stephano
--

[Alfred via Lazarus]

This post might be inappropriate. Click to display it.

[Michael Ring via Lazarus]

Do you have plans to make it possible to switch debuggers in the same
plugin, too?

This would be very helpful for embedded targets, it is always a pain to
reconfigure gdb when switching between an embedded and a native target.

Could it also be possible to make this plugin project based?


Looks very promising,

Michael

Attached snapshot is work in progress

Sorry, but I don't think this is an improvement. For new users this
looks like a nightmare. It should be hidden, at least, imho. Or
better: make it a plugin.

As Mattias has pointed out, it is a plugin (IDE package), and
definitely not for the faint of heart.
Once one creates a standardized folder hierarchy for the different fpc
versions, it becomes a matter of a few clicks to switch versions.
Stephano

--

[patspiper via Lazarus]

Post by Michael Ring via Lazarus
Do you have plans to make it possible to switch debuggers in the same
plugin, too?

No, as switching debuggers is already possible in the debugging section.

Post by Michael Ring via Lazarus
This would be very helpful for embedded targets, it is always a pain
to reconfigure gdb when switching between an embedded and a native
target.
Could it also be possible to make this plugin project based?

I see now why you asked about debugger switching :)

This feat could be tackled once the plugin is finalized.

Post by Michael Ring via Lazarus
Looks very promising,

Currently a couple of the options (such as fpc debug units) have not
been implemented yet, but the basic features work like a charm.

Stephano

Post by Michael Ring via Lazarus

Attached snapshot is work in progress

Sorry, but I don't think this is an improvement. For new users this
looks like a nightmare. It should be hidden, at least, imho. Or
better: make it a plugin.

As Mattias has pointed out, it is a plugin (IDE package), and
definitely not for the faint of heart.
Once one creates a standardized folder hierarchy for the different
fpc versions, it becomes a matter of a few clicks to switch versions.
Stephano

--

[Thierry B. via Lazarus]

Post by Alfred via Lazarus
That's more a hack then a solution

I fail to grasp why startlazarus should be a feature, and fpc.sh
should be a hack.

Startlazarus is also a hack, because on Windows you can not overwrite an
executable which is open and the design is kept consistent between OS'es.
You can perfectly fine use just 'lazarus' on Linux, I never use
'startlazarus'.

Having multiple fpc.cfg files, as it may be required by multiple fpc
installations requires invoking the compiler with the appropriate
parameters. A script is just the most comfortable way to achieve this
result.

Here is the script I use since several years, that maintain 2 or 3
freepascal/lazarus sets and cross compile from linux to win32 (i don't
need more).
I didn't wrote it, guess I grabbed it from "buildfaq" documentation and
added modified it thereafter. I have to removed hard coded paths inside
but since I had not changes setup for 10 years, it works! And only one
~/.fpc.cfg

https://pastebin.com/eMsq5JLD

TB

--