Hi,

The following applies at least to Linux, and should probably apply as well to other OSes.

When multiple FPC versions are used, the fpc binary and related utilities are usually located in <fpc folder>/<fpc version>/bin, and the compiler itself (ppcxxx) in <fpc folder>/<fpc version>/lib/fpc/<fpc version>. The folders could be different than these, but the point to note is that there are 2 folders that rely on the fpc version.

Furthermore, it is not good practice to specify the ppcxxx compiler in the compiler path in the IDE options, especially when cross-compiling. The fpc binary must be specified instead, and that binary must be able to locate the ppcxxx folder.

I define the compiler path in the IDE options as 'fpc' only, and ensure that both paths above (with the required fpc version to use) are exported in a shell before launching the IDE from that shell (actually I use a script with a menu to select the version). This setup runs smoothly even for cross-compiling.

However to switch from one fpc version to another, one must quit the IDE and the shell, and repeat the process above with the new paths.

In order to avoid quitting the IDE, I suggest the following:

- If the compiler path in the IDE options is set as a relative path to the fpc binary, or more specifically 'fpc' only, then one would assume that the required paths have been exported, and nothing more needs to be done.

- If on the other hand the compiler path in the IDE options is set as an absolute path to the fpc binary (indicating that no paths have been exported), then an additional edit box can be used where one specifies the relative path of the ppcxxx compiler (relative to the fpc binary folder), and thus the IDE can feed that path to the fpc binary using '<absolute path to the fpc binary>/fpc -Xp<relative path of ppc compiler>' when launching the fpc binary. Here two sub cases arise:

* If the FPCVER macro does not appear in any of the 2 paths (<absolute path to the fpc binary> and <relative path of ppc compiler>) then the fpc binary can be queried to set the FPCVER macro.

* If any of the 2 paths depend on the FPCVER macro, then another edit box (with dropdown history) is used to force the FPCVER macro to the required value instead of querying the fpc binary. In that case, changing the FPCVER macro will ensure the use of the right FPC version. As a sanity check, the fpc binary can be queried for the fpc version which is compared to the user specified FPCVER macro.

Thoughts?

Regards,
Stephano

[...] * If the FPCVER macro does not appear in any of the 2 paths (<absolute path to the fpc binary> and <relative path of ppc compiler>) then the fpc binary can be queried to set the FPCVER macro.

The FPCVer always comes from querying the compiler.

Mattias

I don't see that here (Linux/Debian, FPC and Lazarus built broadly with defaults). Binaries are in /usr/local/bin, FPC-specific stuff in /usr/local/lib/fpc/x.y.z where x.y.z is a version number. As a general point, I normally copy a clean fpcsrc into x.y.z for Lazarus's benefit but that still only leaves a single directory named for a version number.

Furthermore, it is not good practice to specify the ppcxxx compiler in the compiler path in the IDE options, especially when cross-compiling. The fpc binary must be specified instead, and that binary must be able to locate the ppcxxx folder.

For users who aren't cross-compiling, why is this a bad idea? (I ask for information, not because I'm arguing or criticising).

I usually add a couple of symlinks in /usr/local/bin e.g. ppcsparc -> ppcsparc-2.6.2 and ppcsparc-2.6.2 -> /usr/local/lib/fpc/2.6.2/ppcsparc. The fpc binary will be the one installed by the most recent build.

Right. But the proposal, if implemented, introduces one case where either the fpc binary or the ppcxxx compiler cannot be located because their paths depend on the FPCVER macro. In that case, the FPCVER macro needs to be manually set/selected in the IDE to allow the paths to resolve correctly. And as a sanity check, the FPC binary can then be queried for the version, and that version is compared with the 'forced' FPCVER macro.

If this is somehow convoluted (for this specific case), then instead of having the paths depend on FPCVER, they could depend on some user defined macro (e.g. USERFPCVER or XYZ) provided the user is able to set that macro in the IDE options via some selector.

Stephano

When you install using the distribution's packages or standard installers, you'll not be able to use more than one FPC version without considerable tweaking.

Furthermore, each version has its own fpc binary and tools in the usr/local/bin folder. They could be compatible or incompatible across versions. Thus it is better for each version to have its own set of folders.

AFAIK, the fpc binary is supposed to be the gate to the compiler, and that's by design. You can get away by using the ppcxxx compiler directly if you're not cross compiling, but that's not guaranteed to not break in the future.

You are tweaking your system unnecessarily. Just make sure that both folder paths are exported and forget about any symlinks. That's by far more flexible, easily upgradeable, and less prone to errors.

Stephano

Executing `fpc -V<versionstr>` will call <ppcbin>-<versionstr>, so those symlinks are actually quite useful if you want to use different compiler versions.

Henry

That's one way for sure, but I'd rather keep my different installs separate and either export the right paths or use the Xp switch.

Btw, are the Xp and V switches documented? fpc does not list them and they cannot be found in
http://www.freepascal.org/docs-html/user/userap1.html#x169-176000A

Stephano

I started off with a standard FPC binary installation circa 2.0, this put the utilities in /usr/local/bin ** . Since then I've generally built from source- in many cases I've had to since there wasn't an up-to-date binary- and I've never had to explicitly tell the build to use non-standard directories.

So if you're now saying that I'm doing something wrong by- in some way- overriding "correct" behaviour then I'm interested to know. Otherwise, what you're suggesting is a significant change to FPC build and I suggest you raise it with the compiler developers- it's not a Lazarus issue.

Furthermore, each version has its own fpc binary and tools in the usr/local/bin folder. They could be compatible or incompatible across versions. Thus it is better for each version to have its own set of folders.

I've never seen any suggestion that this breaks backwards compatibility, and if it does it should probably be raised as a bug- at least so that it can be documented properly. In any event, as long as fpc (etc.) knows what version of backend it's using then later versions should be able to emulate older ones: I don't think anybody'd be fool enough to try the other way round :-)

** On Linux. Solaris was lightly different, and of course Windows has its own "best practice".

I never said you were doing something wrong, although I am not sure what would happen if you uninstall your original FPC. Would the newer built from source versions still work? Moreover, if you install from trunk, then some of the unstable files will be used for all fpc versions. What I do is always build from source, and have several versions coexist without any possibility of conflict since the folders are completely separate.

Otherwise, what you're suggesting is a significant change to FPC build and I suggest you raise it with the compiler developers- it's not a Lazarus issue.

I use standard building (from source) for FPC as if it were a new install, but just make sure each gets its own folder by specifying the INSTALL_PREFIX accordingly. So there is nothing that needs to be raised with FPC devs.

On the other hand, my proposal relates to being able to change the fpc version in the Lazarus IDE on the fly.

Would you trust using the fpc binary (not ppcxxx) and associated utilities of trunk for your production apps?

** On Linux. Solaris was lightly different, and of course Windows has its own "best practice".

:)

Stephano

I have more than one computer :-)

Frankly though, I'm not sure /what/ I'd trust for production apps. I'd be reluctant to use FPC _trunk and cautious about using _fixes, and I think I'd have to say the same about Lazarus... which obviously complicates things since in general there are always "must have" features and fixes only in the bleeding-edge revision.

But that takes us back to the original point: I usually set up Lazarus to invoke ppcXXX.x.y.z rather than the fpc wrapper, at which point I'm not sure which of the utilities in /usr/local/bin are at all relevant.