[fpc-devel] Cross-compiling and warnings from linker

[Sergey Organov]

Tomas Hajny via fpc-devel
<fpc-devel-PD4FTy7X32k2wBtHl531yWD2FQJk+8+b at public.gmane.org> writes:

> On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote:
>> Jonas Maebe via fpc-devel
>> <fpc-devel-PD4FTy7X32k2wBtHl531yWD2FQJk+8+b at public.gmane.org> writes:
>  .
>  .
>> Yeah, I see. However, this file (/etc/fpc.cfg) is part of installation
>> of particular version of FPC provided by corresponding Linux
>> distribution, and is out of control of a person that installs custom
>> (likely more recent) FPC. That's just yet another reason not to read
>> /etc/fpc.cfg unless compiler is installed in /usr/, more so as different
>> FPC versions may have incompatible ideas of its meaning.
>  .
>  .
>> Yep, backward compatibility could be an issue. A solution could be to
>> still read /etc/fpc.cfg if /usr/local/etc/fpc.cfg is not found.
>
> There are valid reasons for having a shared configuration for multiple
> installed versions of FPC (the one in /etc may equally serve for FPC
> installed into /usr/bin/ as well as /usr/local/ and other possible
> places), FPC provides means for specifying certain options
> conditionally there. In general, there's no particular reason why a
> person installing FPC should have rights for installation into
> /usr/local/ but not rights for changing configuration in /etc. If some
> person / user misses such rights, there's already the option of
> placing the configuration file into his or her home directory. Yes,
> /usr/local/etc/ might be added as one more location,
> but the more locations are supported, the bigger risk that users get
> confused due to multiple configuration files with different options
> specified.

The compiler will still read only 2 configuration files at most, the
default for given instance of the compiler, and user's one.

I.e., compiler installed in /usr should *not* read
/usr/local/etc/fpc.cfg, only /etc/fpc.cfg. Compiler installed elsewhere,
say, in /abc/def/custom, should read /abc/def/custom/etc/fpc.cfg.

The idea of backing to read /etc/fpc.cfg if /abc/def/custom/etc/fpc.cfg
is not found for backward compatibility that I've suggested above now
doesn't look useful to me, as I can't figure a use-case where it would
help.

What is indeed confusing is sharing "system" configuration file between
native and cross- compiler. I'd suggest that at least -XR (if not the
installation directory itself) change the search path for configuration
file.

Overall, it's up to you to decide what FPC does, but there are some
agreements in the Linux world that FPC currently doesn't follow, and
those agreements evolved out of practice as being convenient. For
example, I currently have 3 different versions of Git installed, and
each uses its own configuration:

1. In /usr, and it reads /etc/gitconfig
2. In /usr/local, and it reads /usr/local/etc/gitconfig
3. In $HOME/git, and it reads $HOME/git/etc/gitconfig

All of them read user $HOME/.gitconfig in addition, as well as
project-specific configuration in .git/config.

As a user, I have write access to the 3-rd installation only (that I
installed myself), and I have no problems using all these versions. It
could have been useful if Git had support for site configuration common
to all instances, but it's fine without such support as well, while FPC
did surprise me with its behavior.

If you believe FPC should support some configuration that is common for
all the instances of FPC installed on given machine (personally, I doubt
it's that useful for compiler to bother), there probably should be
separate support for the feature. E.g., having "include another config
file" support in the config syntax could be enough for creating
arbitrary flexible configurations, or one can check how, say, Emacs does
this with its "default" and "site" configuration files.

-- Sergey Organov