<div dir="ltr"><div>I am thinking about reducing the patch further to leave only the ability to include config file when clang is called as `target-clang-drivermode`. It is still useful for cross compilation tasks because:</div><div><span style="white-space:pre">       </span>- It is a convenient way to switch between supported targets,</div><div><span style="white-space:pre"> </span>- SDK producer can ship compiler with a set of appropriate options or prepare them during installation.</div><div>In this case if clang is called as `target-clang-drivermode`, it first tries to find file `target-drivermode.cfg` or `target.cfg` in a set of well-known directories, which in minimal case includes the directory where clang executable resides. If such file is found, options are  read from it, otherwise only option --target is added as clang does it now.</div><div><br></div><div>This solution has obvious drawbacks:</div><div><span style="white-space:pre"> </span>- User cannot specify config file in command line in the same way as he can choose a target: `clang --target <target>`,</div><div><span style="white-space:pre"> </span>- On Windows symlinks are implemented as file copy, the solution looks awkward.</div><div>So more or less complete solution needs to allow specifying config file in command line.</div><div><br></div><div>Using `@file` has some problems. Config file is merely a set of options, just as file included by `@file`. Different include file search is only a convenience and could be sacrificed. Comments and unused option warning suppression could be extended for all files included with `@file`. The real problem is the search path. To be useful, config files must be searched for in well-known directories, so that meaning of `clang @config_fille` does not depend on the current directory. So clang must have some rule to distinguish between config file and traditional use of `@file`. For instance, if file name ends with `.cfg` and there is a file with this name in config search directories, this is a config file and it is interpreted a bit differently. Of course, the file may be specified with full path, but this way is inconvenient.</div><div><br></div><div>Another possible solution is to extend meaning of `--target` so that it fully matches with the use of `target-clang-drivermode`, that is the option `--target=hexagon` causes clang first to look for the file `hexagon.cfg` in well-known directories and use it if found. In this case treatment of `--target` is different if the option is specified in command line or in the content of config file (in the latter case it is processed as target name only), it may be confusing. Besides, use of config files is not restricted to the choice of target.</div><div><br></div><div>Using special option for config files does not bring risk of compatibility breakage and does not change meaning of existing options.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Thanks,<br>--Serge<br></div></div>
<br><div class="gmail_quote">2017-05-10 11:25 GMT+07:00 Serge Pavlov <span dir="ltr"><<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">2017-05-10 3:46 GMT+07:00 Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span>:<br></span><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 class="gmail_extra"><div class="gmail_quote"><span class="m_-4899742039534227284gmail-"><span class="">On 1 March 2017 at 02:50, Serge Pavlov via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Format of configuration file is similar to file used in the construct `@file`, it is a set of options. Configuration file have advantage over this construct:<br>
<br>
- it is searched for in well-known places rather than in current directory,<br></blockquote><div><br></div></span></span><span class=""><div>This (and suppressing unused-argument warnings) might well be sufficient to justify a different command-line syntax rather than @file...</div></span></div></div></div></blockquote><div><br></div><div>Construct
`@file` in this implementation is used only to read parts of config file inside containing file. Driver knows that it processes config file and can adjust
treatment of `@file`. On the other hand, driver might parse config files in a
more complicated way, for instance, it could treat line `# include(file_name)`
as a command to include another file.</div><span class=""><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_-4899742039534227284gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- it may contain comments, long options may be split between lines using trailing backslashes,<br>
- other files may be included by `@file` and they will be resolved relative to the including file,<br></blockquote><div><br></div></span><div>... but I think we should just add these extensions to our @file handling, and then use the exact same syntax and code to handle config files and @file files. That is, the difference between @ and --config would be that the latter looks in a different directory and suppresses "unused argument" warnings, but they would otherwise be identical.</div></div></div></div></blockquote><div><br></div></span><div>Changing treatment of `@file` can cause compatibility issues, in particular, both libiberty and cl resolves file name relative to current directory. So driver must deduce that `@file` is used to load config file rather than merely to organize arguments. Another difference is that `@file` inserts its content in the place where it occurs, while `--config` always puts arguments before user specified options. The following invocations:</div><div><br></div><div>    clang --config a.cfg -opt1 -opt2 file1.cpp</div><div>    clang -opt1 -opt2 file1.cpp --config a.cfg</div><div><br></div><div>are equivalent, but variants with `@file` can have different effect.</div><span class=""><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_-4899742039534227284gmail-"><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">
- the file may be encoded in executable name,<br>
- unused options from configuration file do not produce warnings.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D24933" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2493<wbr>3</a><br>
<br>
<br>
<br>
</blockquote></span></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>