Secondary Installation for *nix

[Warfley]

One thing I noticed thats a bit of an issue when doing an installation on Linux or other unix systems, is that there seems to be no easy way to perform a secondary installation, as the install.sh script ALWAYS installs a global fpc.cfg.

I did fix this in an MR to the fpc build repo:https://gitlab.com/freepascal.org/fpc/build/-/merge_requests/1
But because it seems like no one looks at this repo, I wanted to post here to make note of it. Basically the fix boils down to two changes. First the FPC is symlinked, but when searching for the fpc.cfg it checks relative to the compiler path. So when the compiler is installed in $PREFIX/lib/fpc/$VERSION and symlinked to $PREFIX/bin, it will not search in $PREFIX/etc but in $PREFIX/lib/fpc/etc
The second problem is that the install script always installs the fpc.cfg to /etc overwriting any other FPC config, usually the one of the native fpc installation (from the package manager) and thereby more often than not breaking something. Instead it should be installed to $PREFIX/etc where, together with the change above, it will be found by the fpc.

So with that change now the install script can be used to do a secondary installation of fpc without breaking the primary installation, and without having to manually install a fpc.cfg

[MarkMLl]

One thing I noticed thats a bit of an issue when doing an installation on Linux or other unix systems, is that there seems to be no easy way to perform a secondary installation, as the install.sh script ALWAYS installs a global fpc.cfg.

Except for unices where it doesn't create one at all :-/

I did fix this in an MR to the fpc build repo: https://gitlab.com/freepascal.org/fpc/build/-/merge_requests/1
But because it seems like no one looks at this repo, ...

That might explain why I've taken stick from the likes of various people for being sufficiently bold to install FPC using the distributed fpcbuild bundles. I think I'd better take a look what's in there...

Thanks for the hint and overall work.

MarkMLl

[Thaddy]

Except for unices where it doesn't create one at all :-/

The makefile installs a fpc.cfg in /etc
Always, afaik.

The trick is that ou must version that one twice, so that you can configure multiple installs to use the versioned fpc-x.x.x.cfg's

You can subsequently use the info in https://www.freepascal.org/docs-html/user/usersu10.html#x24-310003.1.5

[MarkMLl]

Except for unices where it doesn't create one at all :-/

The makefile installs a fpc.cfg in /etc
Always, afaik.

QED :-/

MarkMLl

[Thaddy]

Yes.
but see:
https://www.freepascal.org/docs-html/user/usersu10.html#x24-310003.1.5

where it is explained how to separate multiple configs by putting an ./etc on top of the installation dirs.
e.g.
/usr/bin/fpc331/etc
/usr/bin/fpc323/etc

[Warfley]

where it is explained how to separate multiple configs by putting an ./etc on top of the installation dir.

Yes but this is, as I described in the first post also not straight forward, because one may assume the installation directory is the bin directory in the prefix, because thats where the stub lies, but the ppcXXX are just symlinked from the lib/fpc/version directory, so you must put the fpc.cfg in an etc folder relative to them.

This makes it very annoying

[Thaddy]

That is true, hence I do that in a shell script or otherwise manually

[marcov]

During the 1.9.2 cyclus (beta for 2.0) , there was some experimentation with that, but it was never made default because getting the path of the running binary depends highly on OS and filesystem (think e.g. network filesystems).

Originally OS X couldn't do it, but afaik Jonas found a way for the common case over the years.

[Thaddy]

I only described the case for a local install.
I guess Jonas introduced the options as described in the manual.

[Warfley]

I mean the problem is currently the install script is simply broken, wenn you chose a custom install path, it shouldn't just overwrite the global fpc config path.

So if the relative config path is not fully supported, the install script could do something like if the default global install path is chosen (/, /usr, /usr/local) the default fpc config prefix is the global prefix (/etc). If the user chooses a different prefix, the relative etc path is chosen (like in the MR I did).
BUT in any case, the user should be asked what path the configs should be generated into. And in case it is not fully supported on the target platform it may issue a warning.

Because the main system where it is used is probably Linux where it does work. So having it broken for all systems where it does work, including Linux, just because on some systems it doesn't seems like a bad tradeoff.

I'm also willing to make these changes in the bash script myself in the merge request, I just need to know what the requirements are

[TRon]

@Warfley:
Yes, because the install script creates a fresh new configuration file, overwriting the existing one (not merging) this is problematic.

Reason for me to not rely on a global fpc.cfg but, as you rightly noticed not obvious for newcomers.

Easiest to solve is use a custom fpc.cfg (and yes, fpcmkcfg can be adjusted to create a custom (default) fpc.cfg) that isn't bound to a single version of FPC.

fwiw: I myself use a FPC script that forces my custom configuration file that works for all FPC versions. On the other hand, I do not use the default installation locations.

That way whenever I locate a fpc.cfg and/or lazarus configuration directory in one of the default locations I know for sure that I screwed up somewhere along the line.

Currently manual setup of configuring the compiler correctly is required when wanting multiple installations.

[Warfley]

I'm always having one global installation kept up to date through the package manager, so I can just pop open a console and use fpc, use the same fpc version in differen lazarus installations (as the release cycle of lazarus is so much faster than fpc that we use the same fpc version since pre lazarus 2.2.0), etc.

This FPC version I use for like 99% of things, usually I only have a few trunk/main installations going for testing stuff or my own development copy, which I install from source.

So when I recently wanted to check out how well the snapshot builds work, and wanted to exectued the install script with a custom location, it was quite a surprise that suddenly all of my configurations that use the system fpc stopped working, a purely joyful moment :)

This is why I made this merge request, because the install script can already install into custom locations, the only thing that skrews this up is the config file

[Thaddy]

You may get away with -n and subsequenty -t</path/someversionedfpc.cfg>
1. -n ignores fpc.cfg
2. -t</path/someversionedfpc.cfg> reads also configuration from a specified config.
During make, use OPT= for both.

I knew about the -n option in combination with @/path/myfpc.cfg, which only reads myfpc.cfg
Forgot about the -t<> option.

All this is scriptable.

[Warfley]

Sure, but this doesn't change the main problem, that the official install script should not interfere with an existing installation if not explicitly promted to do so (e.g. when doing an update of an existing installation).

If I install fpc into a non system directory, it should not overwrite the configuration for the system installation

[TRon]

So when I recently wanted to check out how well the snapshot builds work, and wanted to exectued the install script with a custom location, it was quite a surprise that suddenly all of my configurations that use the system fpc stopped working, a purely joyful moment

This is why I made this merge request, because the install script can already install into custom locations, the only thing that skrews this up is the config file

I understand but tinkering is still required f.e. when using cross-compilers. A single fpc.cfg as a global option that every installation is able to tinker with simply isn't an option for me (too many times bitten by it).

Therefor I personally use something similar as Thaddy's suggestion (and out of global system context, except for a single link that no other software/FPC/Laz is able to mess with).