<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 10:59 AM, Serge Pavlov
wrote:<br>
</div>
<blockquote
cite="mid:CACOhrX6NZLnWhmtFiCtfdha0LtbhD5dd8KVgA+JaVwZ-9+okow@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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.</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Right.<br>
<br>
<blockquote
cite="mid:CACOhrX6NZLnWhmtFiCtfdha0LtbhD5dd8KVgA+JaVwZ-9+okow@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div> 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>
</div>
</div>
</div>
</blockquote>
<br>
Can't you just make it configurable? If parsing an `@file`, do the
old thing, otherwise, do the new thing?<br>
<br>
<blockquote
cite="mid:CACOhrX6NZLnWhmtFiCtfdha0LtbhD5dd8KVgA+JaVwZ-9+okow@mail.gmail.com"
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">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>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CACOhrX6NZLnWhmtFiCtfdha0LtbhD5dd8KVgA+JaVwZ-9+okow@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</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>