<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 03/15/2017 12:04 PM, Serge Pavlov
wrote:<br>
</div>
<blockquote
cite="mid:CACOhrX4BoB-KUHvRdOb4XzmP2h2C6spJvkO7so7phv-H5ycJwA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">Thanks,<br>
--Serge<br>
</div>
</div>
<br>
<div class="gmail_quote">2017-03-15 23:21 GMT+07:00 Hal Finkel
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</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 bgcolor="#FFFFFF"><span class="gmail-">
<p>On 03/15/2017 10:59 AM, Serge Pavlov wrote:<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div>It looks like the features that may be
added to the file format in `@file` construct
without disturbing existing functionality are:<br>
</div>
</div>
</div>
</blockquote>
</span><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div><span class="gmail-m_-5995033795877453493gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>-
comments,</div>
<div><span class="gmail-m_-5995033795877453493gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>-
splitting long lines with trailing '\',</div>
<div><span class="gmail-m_-5995033795877453493gmail-Apple-tab-span" style="white-space:pre-wrap"> </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>
</div>
</div>
</div>
</blockquote>
<br>
</span> Can't you just make it configurable? If parsing
an `@file`, do the old thing, otherwise, do the new
thing?<span class="gmail-"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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 moz-do-not-send="true"
href="https://reviews.llvm.org/D24933"
target="_blank">https://reviews.llvm.org/<wbr>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>
</div>
</div>
</blockquote>
<br>
</span> Maybe I'm missing something, but I think you're
taking this the wrong way. I don't recommend giving up
features in this sense. I think the question is: can we
replace the current `@file` processing with the new
config-file logic (just with some of the new features
turned off)?<br>
<br>
If that can't be done reasonably, then I think that's
okay too. We just should understand (and document) why.<span
class="gmail-HOEnZb"><font color="#888888"><br>
<br>
</font></span></div>
</blockquote>
<div><br>
</div>
<div>I understood the question as "can we load config files
with @file not with new option", there were such opinions
in this thread above. If the question is only about
enhancements to processing of `@file`, the reply is yes.
In the LLVM part of this patch config file parsing in
implemented on top of `@file` processing (<a
moz-do-not-send="true"
href="https://reviews.llvm.org/D24926">https://reviews.llvm.org/D24926</a>,
function `cl::tokenizeConfigFile`). It seems to me that
comments and using '\' to glue lines may be enabled in
`@file` as well, as an extension. Other features may be
enabled for config files only but clang must somehow know
that the file contains configuration.</div>
</div>
</div>
</div>
</blockquote>
Sounds good. I'll look at the patches.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CACOhrX4BoB-KUHvRdOb4XzmP2h2C6spJvkO7so7phv-H5ycJwA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Thanks,</div>
<div>--Serge</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>