Hi,

Is there a recommended or usual way to install multiple FPC versions and one fpc.cfg per version under Linux/Unix?

fpc 2.6.2 and 2.7.1 search fpc.cfg under Linux:

Configfile search: /home/mattias/.fpc.cfg
Configfile search: /usr/lib/fpc/etc/fpc.cfg
Configfile search: /etc/fpc.cfg

The second is actually
<directory of ppcx64>/../etc/fpc.cfg

So, fpc first searches a user config, then a "flavor" config (e.g. one per version) and the last is the global config.

When installing multiple version of fpc you normally get /usr/(local/)lib/fpc/2.6.2/ppcx86
/usr/(local/)lib/fpc/2.7.1/ppcx86

Because of the '..' in /../etc/fpc.cfg the version vanished in the search. So by default you can not have one fpc.cfg per fpc version.

Mattias

[...] When installing multiple version of fpc you normally get /usr/(local/)lib/fpc/2.6.2/ppcx86 /usr/(local/)lib/fpc/2.7.1/ppcx86

s/x86/x64/

Mattias

I've got a very vague recollection from elsewhere that you can do this sort of thing using a unix-domain (named) pipe. In other words it would probably be something like a "config-file server" daemon listening for attempts to open /etc/fpc.cfg, finding out which backend fpc was attempting to run, and returning (the content of) the appropriate file.

In practice it would probably be easier to patch /usr/local/bin/fpc, or to wrap it in a script which renamed fpc.cfg on the fly.

.
.

In practice it would probably be easier to patch /usr/local/bin/fpc, or to wrap it in a script which renamed fpc.cfg on the fly.

If having different file per version is really necessary (rather than only having differences among versions covered by #IFDEF within a single file), combining an #IFDEF with an #INCLUDE inside the fpc.cfg may be an option. Renaming doesn't sound nicely to me (parallel compilation using different versions, etc.).

Tomas

In our previous episode, Mattias Gaertner said:

I played with this in 1.9.2 times iirc.

IIRC the principle was developed for cases where every version installed into a prefix with make INSTALL INSTALL_PREFIX=~/somethingversion. (so that you also had multiple bin directories and everything was fully separated).

fpc -V also is from that time.

That's the method I use. My installs are as follows:

bin folder: <basefpcfolder>/$(FPCVER)/bin
ppc folder: <basefpcfolder>/$(FPCVER)/lib/fpc/$(FPCVER)

Stephano

Wow.
That's an unexpected solution. :)

Mattias

Yes, for example make install INSTALL_PREFIX=~/2.6.2 installs to ~/2.6.2/lib/fpc/2.6.2
Which looks odd.

Maybe fpc should search for <dir of ppcxxx>/fpc.cfg.

Then maybe the current search for <dir of ppcxxx>/../etc/fpc.cfg can be removed. Only a few people use it and they will probably be happy to have more flexibility where to install fpc.

Mattias

IFDEFs are difficult for scripts.
If you install fpc and there is already a fpc.cfg, what IFDEFs should be added?

Mattias

Why not fpc-$FPCVERSION.cfg? And keep them all in /etc/ ? fpc-2.6.2.cfg, and fpc-2.7.1.cfg, etc.
This way fpc will use it's version and search for the right one in a standard directory?

- Dennis Fehr

In our previous episode, Mattias Gaertner said:

For that it does. If you however install FPC in /usr/local (like the ports dir) it make sense. Binaries end up in $PREFIX/bin, config in $PREFIX/etc and rest in $PREFIX/lib. relative to the bin, etc is at ../etc.

(and *BSDs have etc dirs in other prefixes too, distributing the config files, /etc mostly contained config files from the base distro)

I don't think it was ever meant for distribution conforming installs, since they don't carter for multiversion systems.

Maybe fpc should search for <dir of ppcxxx>/fpc.cfg.

Unix doesn't mix configs and binaries, so this IMHO is strange. Configs go into etc dirs, not bin dirs.

Maybe the solution should be simply to pass params for the LIB dir to omit the version number, and then use the toplevel version number.

You can also have easily different gcc versions at least on linux.

In our previous episode, Florian Kl?mpfl said:

> I don't think it was ever meant for distribution conforming installs, since > they don't carter for multiversion systems. You can also have easily different gcc versions at least on linux.

Yes. But then this whole discussion is useless, since afaik gcc hardocdes the prefix.

This layout is actually quite convenient, just change your path and you have a different version:

The trick is basically to run fpc with two switches, and a modified $PATH:
- [-n]: One that disables the default config file
- One that specifies where to look for the config file. (as the quoted text states this should not be required, yet somehow it was for my setup -- I'll need to look into this)

So than you have something like (for revision 26651, obviously): ===== fpc-26651 =====
#!/bin/sh
PATH="/compilers/fpc/26651/bin":$PATH" fpc -n
@/compilers/fpc/26651/etc/fpc.cfg "$@"
===== ========= =====

I'm not sure if that is really what you need, but I think this is the most flexible/straightforward method of `running one fpc.cfg per fpc version`.

It is the most flexible, I agree with that.

Most straightforward:
Without the '..' it could be more straightforward, because you would not need the -n @.

My point is:
The current search <dir>../etc/fpc.cfg does not work with the current defaults of "make install". The following would be better:

<dir>/etc/fpc.cfg
or /etc/fpc-<version>/fpc.cfg
or /etc/fpc.d/<version>.cfg

I agree with Marco that the first is not *nix like.

Mattias

In our previous episode, Mattias Gaertner said:

And none of all address the duplication of binaries in the bin directories.

This is getting slightly out of hand.

I don't think there is a problem to begin with.

You can perfectly cater for different FPC versions in 1 config file. It has support for ifdef, include and whatnot.

See
http://www.freepascal.org/docs-html/user/userse17.html

That means you can simply have a config file

#ifdef ver2_6_0
#include /etc/fpc.d/260.cfg
#endif
#ifdef ver2_6_2
#include /etc/fpc.d/260.cfg
#endif
#ifdef ver2_7_1
#include /etc/fpc.d/260.cfg
#endif

You can probably even have (I would need to check this)

#include /etc/fpc.d/$FPCVERSION$.cfg

and any possible variation of this scheme. It's the problem of the packager to organize this.

What more do you need ?

Michael.

[...] And none of all address the duplication of binaries in the bin directories.

True.

Mattias

In our previous episode, Mattias Gaertner said:

My point is: The current search <dir>../etc/fpc.cfg does not work with the current defaults of "make install". The following would be better:

(I missed this earlier). It is /geared/ towards multiple "make install". Just not "make install" into the same prefix.

Nice. Can this be added by default?

BTW, documentation is somewhat off:

Users manual 2.2:
"The compiler will first look for a file .fpc.cfg in your home directory before looking in the /etc directory."

It does not mention the <dir>/../etc/fpc.cfg, nor PPC_CONFIG_PATH. Perhaps it should refer to chapter 3.1.5?

Users manual 3.1.5:
It does not mention the <dir>/../etc/fpc.cfg.
It should explain, that dir is the directory of the ppcxxx executable (/usr/lib/fpc/2.6.2), not the dir of the symlink in PATH (e.g. /usr/bin).

and any possible variation of this scheme. It's the problem of the packager to organize this.

The packager is often only responsible for the release version. The other versions are then installed by the user.

What more do you need ?

I'm investigating what Lazarus needs to support to switch fpc versions more easily. That's why I'm collecting all the possibilities how people install multiple versions of fpc. I'm puzzled of the amount of different approaches - I thought two were enough. I wonder if some of them exists only because the user did not know the alternatives.

Is there already a doc about how to install multiple versions of fpc?

Mattias

I can add my own flavor as well. :D

I have fpc installed in /mnt/data/applications/$FPCVERSION with the usual dir structure underneath. In ~/.bin I have symlinks for fpc, fpcres, fpcmake and various ppcXXX. The directory is also in PATH. In ~/.config/fpc I have various fpc.$FPCVERSION.cfg and ~/.fpc.cfg is a symlink as well. All these symlinks are updated with a switch-fpc script that gets the version to symlink to as argument.

Regards,
Sven

Not like this, because the compiler would complain if not finding it for a particular previously installed version.

Tomas

For Lazarus switching should work without invoking a script or changing a file. Only environment variables and parameters.

Mattias

On Mon, February 17, 2014 13:24, Mattias Gaertner wrote:

.
.

.
.

I guess that it's at least partly also due to different needs and preferences of different people. If I use one FPC version most of the time and only want to keep older versions for occassional regression testing, I do not need any sofisticated solution. Moreover, different fpc.cfg versions are not necessarily wanted in this case, because different parameters would make comparing the behaviour among FPC versions more difficult.

For Lazarus switching should work without invoking a script or changing a file. Only environment variables and parameters.

Still, my open question is: what are the drivers for needing to support (= having to maintain) different fpc.cfg files for different FPC versions? Moreover - if people use different approaches and want to have different versions and different locations (differing per distribution, user preferences, etc.), can't you simply let them to choose their preferred approach in Lazarus explicitly (either using single fpc.cfg for everything, or having version specific files configured explicitly by the user when setting path to his FPC installations)?

Tomas

I noticed. I will fix that.

I myself didn't even know the behaviour for ../../version/whatnot... I must dive into the sources to fix this oversight in the docs.

True.

Probably you hit the nail on the head there :)

Is there already a doc about how to install multiple versions of fpc?

No, because
a) There are so many ways to do it
b) There are so many platforms.
I prefer to document the possibilities and let the user figure out for himself what works best.

I do think we can certainly make the default behaviour more 'version aware' by installing a config file that already implements one of the different schemes.

That said, I am still not convinced of the need for this, I work since many years with a single pretty standard config file, which I've never had to edit.

Michael.

True. That's because the FPC team did a great job, so that in most cases the standard fpc.cfg works with multiple versions.

Well, I thought too that those two approaches are enough. But people use -FD, -Xp, -V, @, PATH, PP, PPC_CONFIG_PATH, PPC_EXEC_PATH, symlinks, scripts, etc. I wonder if Lazarus should provide GUI elements for them.

My dream:
User installed some FPC versions, Lazarus finds all available versions and user can choose from the list. If it is not in the list, the user selects once the new compiler and Lazarus adds it to the list.

Mattias

At least that should be possible on Unices.
/usr/(local/)lib/fpc/versions gives you the default versions.

What we could do from the FPC side is maybe let fpc -iXYZ output the available versions. Assuming a default install, this should be possible

Michael.

Mattias Gaertner wrote

On Mon, 17 Feb 2014 14:14:03 +0100 "Tomas Hajny" wrote:

.
.

I'm not sure whether all these approaches used from the command line need to be catered for by Lazarus. Some of them (e.g. script and symlink solutions for selecting a particular version) are in fact directly replaced by Lazarus _when_using_Lazarus_ (users may obviously continue using them from the command line to address their specific needs there). People creating such solutions for themselves should probably understand well that the behaviour with Lazarus may be different and do not expect Lazarus to reverse engineer their scripts. ;-) BTW, the same is true for the text mode IDE and the command line compiler.

Tomas

That's definitely a good thing.

The next step would be to create an example. I guess a common setup is the latest release and trunk.

Let's say I start such a page.

Then I would explain the two common setups

The clean approach:
1.1. read Michael's docs
1.2. install the latest released compiler
1.3. download the trunk sources, compile it
1.4. "make install INSTALL_PREFIX=~/fpc/2.7.1"
1.5. setup a fpc.cfg (~/fpc/2.7.1/lib/etc/fpc.cfg), add -FD~/fpc/2.7.1/bin and adapt the -Fu lines.

Then you can select the 2.6.2 via /usr/bin/fpc or the 2.7.1 via ~/fpc/2.7.1/lib/2.7.1/ppcx86.

The shared approach:
1.1. read Michael's docs
1.2. install the latest released compiler
1.3. download the trunk sources, compile it
1.4. "make install INSTALL_PREFIX=/usr"

Then you can select the 2.6.2 via /usr/lib/fpc/2.6.2/ppcx86 or the 2.7.1 via /usr/lib/fpc/2.7.1/ppcx86.

Beware that you now use the 2.7.1 tools (e.g. /usr/bin/fpcres). There are some corner cases where this does not work. Then you need the clean approach.

I do think we can certainly make the default behaviour more 'version aware' by installing a config file that already implements one of the different schemes. That said, I am still not convinced of the need for this, I work since many years with a single pretty standard config file, which I've never had to edit.

I use the standard config file since many years as well.

Mattias

In our previous episode, Mattias Gaertner said:

I mostly use the "clean" approach, but have a simple scripts that swaps links from ~/bin to ~/fpc/$FPCVERSION/bin

This because I also need access to the fpcmake of 2.6.x for 2.6.x maintenance etc.

Calling ppcxxx directly breaks easy cross compilation using build modes.

Better provide for every fpc version the path to fpc and the path to the corresponding ppc(s) so that Lazarus can call:
<pathtofpc>fpc -Xp<pathtoppc>

or even:
<pathtofpc>fpc -Xp<pathtoppc> -FD<pathtotools>

Stephano

Not if the IDE is aware of this.

Michael.

Yes, but that would mean extra coding in the IDE just to duplicate fpc functionality. It will probably add as well the burden of maintenance whenever new targets are added to fpc.

Stephano

I agree that the best option would be to use the -V and -P options of fpc.

But, for this, it would be best if fpc can list the available versions and architectures/cross-compilers.

Michael.

Assuming that list of supported FPC installations should be configurable by the user in Lazarus settings, listing of versions wouldn't be necessary (it would be incomplete anyway in many cases). I see no use for -V in this use case either (due to differences between global and local installations and also installations in non-standard places). I believe that -Xp should cover everything needed (at least as long as that parameter is supported by the installed FPC version; if not, invoking fpc with a modified PATH would be my suggested solution).

Tomas

Indeed - the IDE doesn't need to call ppcx86 directly, but it can simply pass ~/fpc/2.7.1/lib/2.7.1/ to fpc via -Xp and let it do its job (it should also call fpc from ~/fpc/2.7.1/lib/2.7.1/ in such a case to cater for situations like support of a new platform support not available with the latest released version).

Tomas

I think you are wrong.

-Xp is there for the case you have a special setup.

-V is there for standard installations, so you don't need to know the paths.

I think it is by far preferable to use the latter. If you're not going to use/encourage it, you'd better remove it altogether.

Michael.

In our previous episode, Michael Van Canneyt said:

But -V doesn't have fixed path requirements. It requires the user to set the correct symlinks.

I am not so keen on using -V as it requires extra steps to be done beyond fpc's 'make install'. On the other hand, -Xp can handle vanilla make installs (based on the "clean approach"). Moreover, I prefer not to use the same bin folder for executables from different versions, and have instead completely separate top folders.

But, for this, it would be best if fpc can list the available versions and architectures/cross-compilers.

+1

On a side note, for 2.7.1, 'fpc -h' shows the -V and -Xp options whereas 'fpc' alone (requires the pressing of <enter> to view successive pages) does not.

Stephano

I suggested that Lazarus has for every fpc version the following info:

- Path to fpc
- Path to ppc
- Tools path (optional)

It could then use:
<pathtofpc>fpc -Xp<pathtoppc> -FD<pathtotools>
with the -FD part being optional

Stephano

I certainly don't need to be right here ;-) but my thought was that if Lazarus wanted to cater for both standard installations (releases) and non-standard ones (allowing users to configure them inside Lazarus rather than expecting that Lazarus should detect them automatically, of course) as suggested by Mattias in his earlier e-mail, using -Xp would be a more generic solution.

That obviously does not imply that -V shouldn't be used with fpc for other use cases, it's just that it may not fit the Lazarus need completely (as far as I understood Mattias correctly, of course).

Tomas

No, sorry, I didn't phrase that correctly.
My phrasing was a bit crude, I should have written that I don't share your point of view here. Crude phrasing happens if you answer too quickly :(

Well, generally speaking I think that -Xp should not be there to begin with. Starting from there, recommending its use is, obviously, even worse practice :)

But it's up to the lazarus team to see what solution they prefer.

I will limit myself to documenting the various possibilities :-)

Michael.

Since I'm a compiler developer I'm not running purely the IDE as I often need to "make cycle" the compiler or to "make clean all" a full build. This approach allows me to easily update the release compiler without having to think that much about it (except that a new release install requires a new fpc.cfg).

Regards,
Sven

patspiper wrote

On a side note, for 2.7.1, 'fpc -h' shows the -V and -Xp options whereas 'fpc' alone (requires the pressing of <enter> to view successive pages) does not.

Are you sure that fpc is picking up the correct ppcX (help output is always generated by the ppcX)? Because for me it works.

Regards,
Sven

Unless I am doing something foolish, I am getting these results:

/home/me/Programs/fpc/2.7.1/bin/fpc
-Xp/home/me/Programs/fpc/2.7.1/lib/fpc/2.7.1 -h
shows -V and -Xp

/home/me/Programs/fpc/2.7.1/bin/fpc
-Xp/home/me/Programs/fpc/2.7.1/lib/fpc/2.7.1
No -V and -Xp

/home/me/Programs/fpc/2.7.1/lib/fpc/2.7.1/ppc386 -h No -V and -Xp

/home/me/Programs/fpc/2.7.1/lib/fpc/2.7.1/ppc386
No -V and -Xp

In all cases, 'Free Pascal Compiler version 2.7.1 [2014/02/08] for i386' is shown at the top of the help.

Stephano

Well, I meant `straightforward` more with respect to usage, not with respect to the actual magick involved. This approach allows me to run any fpc version by simply running fpc-<rev. number> on the command line. In that respect I think it is straightforward.

OTOH the involved switches seem to be a bit more exotic (as the 2.6.2 release does not even mention @, -Xp or -V in `fpc -help`) and this is indeed not so straightforward. Nonetheless, they are there and thus could be used.

As to answer another question you had: No, I don't use this approach because it's the only one I know, I use it because it suits my purposes best. I looked into several other ways of running multiple freepascal compilers on my machine (almost all of which have been stated by others) and this was simply the one that required the least effort and gave me exactly what I wanted.

This last one would introduce problems though, since all trunk version are currently version 2.7.1. Substituting <version> for a revision number would be possible, but it would make a terrible mess of your /etc directory IMHO.

I haven't checked it yet, but I suspect that I hadn't tested the behaviour under any Unix platform when adding the hack for displaying the fpc-specific options by ppcX if and only if invoked by the fpc wrapper. It might be that my solution doesn't work reliably under Unix. I'll have a look at it and possibly try to fix it.

Tomas

Let's see:

When the user selects a different target OS the compiler can be kept (or see below).

When the user selects a different compiler (e.g. ppc386), the IDE could find out the target CPU. So if the target CPU setting is "default", the IDE could automatically use i386.

When the user selects a different CPU, the IDE could select the last used compiler for this CPU.

So in many (most?) cases it is enough to change one option.

And last but not least: If you use build modes it does not matter much how many options you have to setup. The point of build modes is that you do that only once.

Better provide for every fpc version the path to fpc and the path to the corresponding ppc(s) so that Lazarus can call: <pathtofpc>fpc -Xp<pathtoppc>

That's two parameters.

Keep in mind that "fpc" is only a frontend to help selecting the right compiler (i.e. saving some typing and searching). An IDE is a frontend too.
If you pass -Xp then the only thing that fpc does is the mapping from OS/CPU to ppcxxx.

or even: <pathtofpc>fpc -Xp<pathtoppc> -FD<pathtotools>

See the the various mails of this thread: -FD is only needed if your fpc.cfg is incomplete.

Mattias