<div dir="ltr">My main concern with configuration files is that they should interact with regular command line flags in a predictable and maintainable way. Your approach of extending response files seems like it's going in the right direction.<div><br></div><div>I'm not excited about adding something like ELLC's YAML format to Clang (<a href="http://ellcc.org/viewvc/svn/ellcc/trunk/libecc/config/ppc64el-linux?view=markup">http://ellcc.org/viewvc/svn/ellcc/trunk/libecc/config/ppc64el-linux?view=markup</a>) because then we will have to document and maintain the semantics of things like multiple configuration files, in what order they override each other, and how they interact with flags. Our command line flag logic is already too complicated. We have one public interface, and it's flags, and I'm hesitant to add a new one.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 19, 2016 at 1:06 AM, Serge Pavlov via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>I would like to propose implementing configuration files in clang. The idea is to read some set of options prior to the options specified in a command line in every tool invocation. These options are taken from a file which is searched either in predefined place or its location is specified by environmental variable.</div><div><br></div><div>Few words about particular problem this facility can solve. Clang issues many warnings, some refer to potential errors, some merely attract attention to code that can cause problems in some circumstances but otherwise is pretty innocent. For example, warning -Wundefined-var-template is issued for template usages, which nor cannot be instantiated implicitly neither are mentioned in explicit instantiation declarations. Such usage is not an error or bad style, but the warning may be helpful for a user in a complex case, such as described in PR24425. For other users this warning may be annoying and they would prefer to turn it off by default (see discussion in <a href="http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160808/167354.html" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-commits/Week-of-<wbr>Mon-20160808/167354.html</a>). Different categories of users like to have different set of warnings enabled by default.</div><div><br></div><div>If configuration files were supported by clang, a user can put -Wno-undefined-var-template to such file and this would have the same effect as if the unwanted warning were turned off by default. No changes to build scripts would be required.</div><div><br></div><div>Configuration files are supported by the Intel Compiler (<a href="https://software.intel.com/en-us/node/522780" target="_blank">https://software.intel.com/<wbr>en-us/node/522780</a>) and similar behavior is proposed to be implemented by clang.</div><div><br></div><div>By default the configuration file is searched in the same directory where tool executable resides. In the case of clang the file would be 'clang.cfg', for other tool named 'foo'- 'foo.cfg'. User can specify any location for this file if he sets up environmental variable 'CLANGCFG' (or 'FOOCFG'). The variable should contain path to configuration file. If the configuration file does not exist, it is silently ignored. Content of configuration file is treated as a part of command line of each tool invocation preceding any arguments specified in command line.</div><div><br></div><div>Does implementation of this facility makes sense?</div><div><br></div><div><div class="m_-6253681486997706616gmail_signature">Thanks,<br>--Serge<br></div></div>
</div>
<br>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>