<div dir="ltr">Hi all,<div><br></div><div><div>Implementation is presented in <a href="https://reviews.llvm.org/D24933">https://reviews.llvm.org/D24933</a>. It is limited to the case in which user explicitly specifies config file, either by option `--config` or by using mangled compiler name, like `armv7l-clang`. Its main goal is to simplify use of clang when command line contains many options that are the same for many invocations. The other use case is default config file, which is applied automatically. This case is not presented in this implementation to simplify review process.</div><div><br></div><div>To move forward additional feedback is necessary, mainly to decide whether this feature is worth implementing. Config files may be convenient in the cases in cross-compilation. So far, there is a positive opinion about using config files in clang based cross compilation environment: <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>.</div><div><br></div><div>Some express concern that this is not a useful feature, the main points are listed below.</div><div><br></div><div>1. Config files vs `@file`</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">  </span></div><div>There is an opinion that the functionality provided by config files is already available through the directive `@file`. Both config file and `@file` specify a set of command line options, but config file has some advantages:</div><div>- It searches well-known places for files, while `@file` must search only the current directory,</div><div>- It may include other config file, they are resolved relative to including file, making it possible to move set of related files across file system. Nested `@file` searches only current directory. Coupled with above note it means that using `@file` directive requires all files be specified by absolute paths, if we want to reference the same files during build process.</div><div>- Config files may contain comments,</div><div>- Options from config file do not produce warning 'unused option' even if they are indeed unused.</div><div><br></div><div>Ability to contain comments is not only a convenience for maintenance. It can be useful for extending functionality. We can assume, for instance, that if the first line is a comment of some special form, such as `#!yaml` or `# format = xml` or some other, then it specifies format of the config file. This would allow  extending functionality of config files in future without breaking compatibility.</div><div><br></div><div>2. More elaborated solutions</div><div><br></div><div>Many are of opinion that config file in this form is too primitive solution, for instance:</div><div>- A good solution must be able to deduce target from arguments (-m32),</div><div>- 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,</div><div>- Config file must reduce complexity of clang driver.</div><div><br></div><div>The presented implementation of config files is only a way to specify set of options, it cannot solve these problems. However it can be extended in future so that, for instance, the following construct could be allowed (particular syntax does not matter):</div><div><br></div><div>    …</div><div>    #if (argv.contains("-m32"))</div><div>    -target i686-unknown-linux-gnu</div><div>    #else</div><div>    -targer x86_64-unknown-linux-gnu</div><div>    #endif</div><div>    …</div><div><br></div><div>This syntax would require to support `if/else/endif` control construct, and builtin function `argv.contains`. Ability to include an option conditionally is likely to be sufficient to solve large part of the problems mentioned above and can indeed reduce complexity of the driver.</div><div><br></div><div>Speaking about ways to make clang driver more flexible and less complex, we need to mention an approach implemented in gcc as `spec files` (<a href="https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html">https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html</a>). A config file, even in the extended form, is only a way to specify a set of options for the driver. A spec file is a set of instructions for the driver how to handle a particular input file. These two solution have different ecological niches and can coexist. A regular user may prepare a set of config files for their needs, these files would capture user-specific information, such as where various components are placed in the user environment. A spec file is more compiler specific, if it needs user information, it would get it from options or environmental variables. As a part of spec file interpretation, the driver must build command lines for compiler, linker and other tools, functionality of config file may be useful in this case too.</div><div><br></div><div>In comparison with the more elaborated solutions mentioned above, the proposed implementation of config files is much simpler and if it is useful, it can be a first step toward more powerful and convenient driver.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Thanks,<br>--Serge<br></div></div>
<br></div></div>