<div dir="ltr">This feature addresses at least two different use cases:<div><br></div><div>1. Config file as a way to override compiler defaults.</div><div><br></div><div>Compiler already has some default settings and it is hardly possible to find the settings that suit everybody. For instance, the warning -<span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Setting config file via environment variable is a variant of this scenario, it allows modification of compiler options without touching build scripts.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Intel compiler implements both default config and environment variable as a way to modify compiler option and practice proved their convenience.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">2. Config file as an "option macro".</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This scenario requires to specify particular config file, either by option --config or by encoding it in compiler executable like clang-conf.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Clang based ELLCC Compiler uses these kind of config files and they are proved to be convenient (</span><span style="font-size:12.8px"><a href="http://lists.llvm.org/pipermail/cfe-dev/2016-September/050783.html">http://lists.llvm.org/pipermail/cfe-dev/2016-September/050783.html</a>).</span></div><div><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">2016-09-28 2:18 GMT+07:00 James Y Knight <span dir="ltr"><<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div></div></blockquote><div> </div><div>For "option macro" scenario it is probably a matter of convenience. For "defaults override" it is not suitable as requires change in build scripts.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>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.<br></div></div><div class="gmail_extra"><br></div></blockquote><div> </div><div>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.</div><div><br></div><div>2016-09-28 1:45 GMT+07:00 Matthias Braun <span dir="ltr"><<a href="mailto:mbraun@apple.com" target="_blank">mbraun@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry for being late to the discussion,<br><br>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!<br><br></blockquote><div> </div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- I'm fine with a commandline option triggering reading a config file (@file)<br>- 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)<br>- Automatically picking up options from user or system configuration files is too dangerous IMO!<br></blockquote><div><br></div><div>Automatic picking up options:</div><div>- is already made by driver,</div></div><div>- is necessary in "defaults override" scenario.</div><div><br></div><div>2016-09-28 1:55 GMT+07:00 Joerg Sonnenberger via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Tue, Sep 20, 2016 at 02:13:42PM +0700, Serge Pavlov wrote:<br>> If full path is specified, options are read from that file. If<br>> configuration is specified by name with optional suffix ".cfg",<br>> corresponding configuration file is searched in the directories in the<br>> following order:<br>> - ~/.llvm<br>> - /etc/llvm<br><br></span>I see no advantage in the additional complexity of new directory<br>searching logic when the user explicitly provides a config name.<br><span class="gmail-"><br></span></blockquote><div> </div><div>A config name is in fact a config file, which need to be found somewhere. It makes sense if:</div><div>- config files are kept in a well known place.</div><div>- 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.</div><div>- A user has possibility to override system configurations.</div><div>As a result we end up with two well-known places: one for "system" configs, one for "user".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> If the option --config is absent, and environment variable CLANGCFG is set,<br>> content of CLANGCFG is used as full path to configuration file. If CLANGCFG<br>> is empty, config file is not used, no diagnostic produced.<br><br></span>I'm not a fan of environment variables for compilers either. You<br>normally can't specify empty environment variables: they are undefined.<br></blockquote><div><br></div><div>Yes, it is too Linux specific. It looks like Windows does not support empty variables. This sentence must be removed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>> If neither --config nor CLANGCFG are specified, default config file is<br>> searched in the following order:<br>> - ~/.llvm/clang.cfg<br>> - /etc/llvm/clang.cfg<br>> - clang.cfg in the directory where clang executable resides.<br><br></span>I'm against a default configuration look up in the home directory. As<br>stated earlier, that would essentially force me to always provide a<br>--config argument in build systems to get consistent rules. /etc/llvm<br>should be the equivalent of --sysconfdir to configure in cmake. I'm<br>against the last as the question of where an executable is located is<br>quite problematic in many situations. If anything, the -B option should<br>be honored here.<br></blockquote><div><br></div><div>Based on feedback I would limit the search for default config file by:</div><div>> - clang.cfg in the directory where clang executable resides.<br></div><div>Reasons:</div><div>- It still allows "defaults override" scenario,</div><div>- A regular user still is able to override compiler defaults if he uses local installation,</div><div>- It allows work with several compilers (compiler developer, CI system),</div><div>- It is the only place which Intel Compiler searches for config files and in practice it is enough.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>> Configuration file is the sequence of compiler options specified in one or<br>> several lines. Lines started with '#' possibly prepended with space<br>> characters are comments, they are ignored. Lines started with '#" in the<br>> first column immediately followed by ':' are reserved for directives. The<br>> file may reference other files using usual syntax for response files:<br>> @included_file. Example of configuration file:<br><br></span>Please don't mix comments with semantics in one syntax form.<br><div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div>This place is not good, agree.</div><div><br></div><div>Thanks,</div><div>--Serge</div><div> </div></div></div></div></div>