Tomas Hajny via fpc-devel <fpc-devel-pd4fty7x32k2wbthl531ywd2fqjk+...@public.gmane.org> writes:
> On 2021-11-22 16:46, Sergey Organov via fpc-devel wrote: >> Jonas Maebe via fpc-devel >> <fpc-devel-pd4fty7x32k2wbthl531ywd2fqjk+...@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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
