[cfe-dev] Configuration files

[Serge Pavlov via cfe-dev]

This feature addresses at least two different use cases:

1. Config file as a way to override compiler defaults.

Compiler already has some default settings and it is hardly possible to
find the settings that suit everybody. For instance, the warning
-Wundefined-var-template
is helpful for some users but annoys others. With config file a user could
put new defaults there and thus customize the compiler. No changes to build
script is required. Note, this scenario requires just default config files.

Setting config file via environment variable is a variant of this scenario,
it allows modification of compiler options without touching build scripts.

Intel compiler implements both default config and environment variable as a
way to modify compiler option and practice proved their convenience.

2. Config file as an "option macro".

Some users, especially those using cross-compilation, want to have
possibility to define an "option" that when applied specifies a set of
other options. An example: switching from one target processor to another
which requires change of sysroot, libraries, triple etc. By organizing
these options into config files, work with several build variants becomes
more convenient.

This scenario requires to specify particular config file, either by option
--config or by encoding it in compiler executable like clang-conf.

Clang based ELLCC Compiler uses these kind of config files and they are
proved to be convenient (
http://lists.llvm.org/pipermail/cfe-dev/2016-September/050783.html).


2016-09-28 2:18 GMT+07:00 James Y Knight <jyknight at google.com>:

> I really don't see what the purpose of this feature is, if it's only going
> to work effectively identically to an "@args-file" option.
>
> If that's all you want, it doesn't even need to be in the clang driver, a
> 5 line shell script that looks at $0 to choose a config file to read can
> work just as well.
>
>
For "option macro" scenario it is probably a matter of convenience. For
"defaults override" it is not suitable as requires change in build scripts.


> But I don't think that's really what people want -- I believe that any
> workable config-file scheme *must* interact with the various target
> specification command-line arguments, and allow for setting options
> dependent upon the actually-selected target.
>
>
You probably mean something like gcc spec file. This is definitely more
extensive work. The simple scheme proposed here may be used to implement
more elaborated solutions.

2016-09-28 1:45 GMT+07:00 Matthias Braun <mbraun at apple.com>:

> Sorry for being late to the discussion,
>
> I think automatic user defaults are a bad idea: Right now when you invoke
> clang without any additional options you know that you are in a well known
> state. Build systems and projects rely on this having unknown compiler
> options active because the user put them into his configuration file is a
> recipe for disaster IMO! The example below "-std=c++14 -fcxx-exception"
> already illustrates a situation in which settings are used that can break
> the compilation of many projects!
>
>
In fact invocation of clang without additional argument does not provide a
well known state. Actual state is represented by options passed from clang
driver to clang compiler, but these options depend on used OS, CPU. In
theory a system upgrade could cause compilation change. Hardly bare driver
arguments can represent compilation options.

Default config file is just a way to influence the magic of option
calculation made by driver. Config files can be used by clang based SDK
suppliers to customize clang without need to modify compiler sources. If
end user plays with default config files, he must know what he does.


> - I'm fine with a commandline option triggering reading a config file
> (@file)
> - Using a different executable name/symlinks to trigger loading of config
> files may be fine as well (build systems should not pick up myarch-clang by
> accident)
> - Automatically picking up options from user or system configuration files
> is too dangerous IMO!
>

Automatic picking up options:
- is already made by driver,
- is necessary in "defaults override" scenario.

2016-09-28 1:55 GMT+07:00 Joerg Sonnenberger via cfe-dev <
cfe-dev at lists.llvm.org>:

> On Tue, Sep 20, 2016 at 02:13:42PM +0700, Serge Pavlov wrote:
> > If full path is specified, options are read from that file. If
> > configuration is specified by name with optional suffix ".cfg",
> > corresponding configuration file is searched in the directories in the
> > following order:
> > - ~/.llvm
> > - /etc/llvm
>
> I see no advantage in the additional complexity of new directory
> searching logic when the user explicitly provides a config name.
>
>
A config name is in fact a config file, which need to be found somewhere.
It makes sense if:
- config files are kept in a well known place.
- SDK supplier provides some set of config files. These may be considered
as "system" configs and in multi-user environment they cannot be changed by
regular users.
- A user has possibility to override system configurations.
As a result we end up with two well-known places: one for "system" configs,
one for "user".


> > If the option --config is absent, and environment variable CLANGCFG is
> set,
> > content of CLANGCFG is used as full path to configuration file. If
> CLANGCFG
> > is empty, config file is not used, no diagnostic produced.
>
> I'm not a fan of environment variables for compilers either. You
> normally can't specify empty environment variables: they are undefined.
>

Yes, it is too Linux specific. It looks like Windows does not support empty
variables. This sentence must be removed.


>
> > If neither --config nor CLANGCFG are specified, default config file is
> > searched in the following order:
> > - ~/.llvm/clang.cfg
> > - /etc/llvm/clang.cfg
> > - clang.cfg in the directory where clang executable resides.
>
> I'm against a default configuration look up in the home directory. As
> stated earlier, that would essentially force me to always provide a
> --config argument in build systems to get consistent rules. /etc/llvm
> should be the equivalent of --sysconfdir to configure in cmake. I'm
> against the last as the question of where an executable is located is
> quite problematic in many situations. If anything, the -B option should
> be honored here.
>

Based on feedback I would limit the search for default config file by:
> - clang.cfg in the directory where clang executable resides.
Reasons:
- It still allows "defaults override" scenario,
- A regular user still is able to override compiler defaults if he uses
local installation,
- It allows work with several compilers (compiler developer, CI system),
- It is the only place which Intel Compiler searches for config files and
in practice it is enough.


> > Configuration file is the sequence of compiler options specified in one
> or
> > several lines. Lines started with '#' possibly prepended with space
> > characters are comments, they are ignored. Lines started with '#" in the
> > first column immediately followed by ':' are reserved for directives. The
> > file may reference other files using usual syntax for response files:
> > @included_file. Example of configuration file:
>
> Please don't mix comments with semantics in one syntax form.
>
> This place is not good, agree.

Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160928/1989dd5a/attachment.html>