<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 11:21 AM, Hal Finkel via
cfe-dev wrote:<br>
</div>
<blockquote cite="mid:2d21b7a9-a6b7-a47e-c914-e27c18689d91@anl.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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">
<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>
</blockquote>
<br>
To elaborate slightly, we currently support `@file` in Clang by
calling llvm::cl::ExpandResponseFiles in Clang's driver. Since this
is general LLVM functionality, and the config-file paring is more
Clang-specific, maybe this is not worth changing. However, what if
we processed `@file` like config files, but in a mode which was
backward compatible with existing `@file` semantics?<br>
<br>
-Hal<br>
<br>
<blockquote cite="mid:2d21b7a9-a6b7-a47e-c914-e27c18689d91@anl.gov"
type="cite"> <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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</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>