<div dir="ltr"><div class="gmail_extra"><div>Hi Hal,</div><div><br></div><div>Thank you very much for your interest and help!</div><div><br></div><div class="gmail_quote">2017-03-15 2:08 GMT+07:00 Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>:<br><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 bgcolor="#FFFFFF">I chatted with Richard about this in person a couple of weeks ago,
and he seems happy with the general direction here. One comment he
had was that it seems like `@file` processing is a restricted case
of config-file processing. As a result, it might make sense to
replace the current `@file`-processing logic with the config-file
processing logic (just with a bunch of features turned off).<span class="gmail-"><br>
<br></span></div></blockquote><div><br></div><div><div>The main issue of using `@file` for loading configuration is compatibility. The construct `@file` has been used for ages and there must be lots of build scripts using it, the change of semantics must not break them. It looks like the features that may be added to the file format in `@file` construct without disturbing existing functionality are:</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>- comments,</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>- splitting long lines with trailing '\',</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>- suppressing warnings on unused options.</div><div>The remaining feature is resolving names in nested `@file` constructs, it must keep current behavior (resolve names relative to current directory). This makes nesting constructs `@file` inconvenient it not useless, but it does not look like a big loss.</div><div><br></div><div>Configuration encoded in compiler file name, as in `armv7l-clang` is not related to `@file`, so this functionality implemented in <a href="https://reviews.llvm.org/D24933">https://reviews.llvm.org/D24933</a> remains unchanged. Explicit specification of config file in command line should be made by `@file` option, there are several issues as compared to the proposed `--config` option:</div><div>- config file must be specified by its full path otherwise it won't be found if the current directory is changed by build script. This limitation should not be a big problem if options are specified in build scripts, but for manual invocations in command line it is inconvenient.</div><div>- command line may contain several `@file` constructs, there may be options before `@file`. If we want to distinguish config file from others (for instance, we want to suppress unused option warnings only in such files), we need to assume that only the first option may load it.</div><div><br></div><div>So if we are ready to sacrifice some convenience, config files can be implemented on top of `@file` construct. If there are no objections I'll update the patch.</div></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"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<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>
</div>
</blockquote>
<br></span>
This is appealing, but I think that we really need to be careful
here. We don't want to create a system where people are encouraged
to replicate complex driver logic in the config files in order to
independently figure out which features might be enabled. Of course,
we already do this, but the logic ends up in wrapper scripts (and is
just as likely to be broken, if not more so). However, if we're
going to create a solution here, we should do so in a way that does
not encourage the confg-file writer to duplicate driver logic.<br>
<br>
In any case, I definitely consider this follow-up work.<br></div></blockquote><div><br></div><div> <span style="font-family:calibri;font-size:11pt">This was
a bad example. To obtain more powerful solution clang need something like gcc
spec files. This is completely different topic.</span></div><div><span style="font-family:calibri;font-size:11pt"><br></span></div><div><span style="font-family:calibri;font-size:11pt">Thanks,</span></div><div><span style="font-family:calibri;font-size:11pt">--Serge</span></div><div><br></div></div></div></div>