<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 02/06/2017 10:05 AM, Serge Pavlov
via cfe-dev wrote:<br>
</div>
<blockquote
cite="mid:CACOhrX6jm0DWZ8C8v6v_PKKG3Z+PcR7AZ47DLDi9DUvy7s5CTA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>
<div>Implementation is presented in <a moz-do-not-send="true"
href="https://reviews.llvm.org/D24933">https://reviews.llvm.org/D24933</a>.
It is limited to the case in which user explicitly specifies
config file, either by option `--config` or by using mangled
compiler name, like `armv7l-clang`. Its main goal is to
simplify use of clang when command line contains many
options that are the same for many invocations. The other
use case is default config file, which is applied
automatically. This case is not presented in this
implementation to simplify review process.</div>
<div><br>
</div>
<div>To move forward additional feedback is necessary, mainly
to decide whether this feature is worth implementing. Config
files may be convenient in the cases in cross-compilation.
So far, there is a positive opinion about using config files
in clang based cross compilation environment: <a
moz-do-not-send="true"
href="http://lists.llvm.org/pipermail/cfe-dev/2016-September/050783.html">http://lists.llvm.org/pipermail/cfe-dev/2016-September/050783.html</a>.</div>
<div><br>
</div>
<div>Some express concern that this is not a useful feature,
the main points are listed below.</div>
<div><br>
</div>
<div>1. Config files vs `@file`</div>
<div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span></div>
<div>There is an opinion that the functionality provided by
config files is already available through the directive
`@file`. Both config file and `@file` specify a set of
command line options, but config file has some advantages:</div>
<div>- It searches well-known places for files, while `@file`
must search only the current directory,</div>
<div>- It may include other config file, they are resolved
relative to including file, making it possible to move set
of related files across file system. Nested `@file` searches
only current directory. Coupled with above note it means
that using `@file` directive requires all files be specified
by absolute paths, if we want to reference the same files
during build process.</div>
<div>- Config files may contain comments,</div>
<div>- Options from config file do not produce warning 'unused
option' even if they are indeed unused.</div>
</div>
</div>
</blockquote>
<br>
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).<br>
<br>
<blockquote
cite="mid:CACOhrX6jm0DWZ8C8v6v_PKKG3Z+PcR7AZ47DLDi9DUvy7s5CTA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>Ability to contain comments is not only a convenience for
maintenance. It can be useful for extending functionality.
We can assume, for instance, that if the first line is a
comment of some special form, such as `#!yaml` or `# format
= xml` or some other, then it specifies format of the config
file. This would allow extending functionality of config
files in future without breaking compatibility.</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>
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>
<br>
Thanks again,<br>
Hal<br>
<br>
<blockquote
cite="mid:CACOhrX6jm0DWZ8C8v6v_PKKG3Z+PcR7AZ47DLDi9DUvy7s5CTA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>Speaking about ways to make clang driver more flexible
and less complex, we need to mention an approach implemented
in gcc as `spec files` (<a moz-do-not-send="true"
href="https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html">https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html</a>).
A config file, even in the extended form, is only a way to
specify a set of options for the driver. A spec file is a
set of instructions for the driver how to handle a
particular input file. These two solution have different
ecological niches and can coexist. A regular user may
prepare a set of config files for their needs, these files
would capture user-specific information, such as where
various components are placed in the user environment. A
spec file is more compiler specific, if it needs user
information, it would get it from options or environmental
variables. As a part of spec file interpretation, the driver
must build command lines for compiler, linker and other
tools, functionality of config file may be useful in this
case too.</div>
<div><br>
</div>
<div>In comparison with the more elaborated solutions
mentioned above, the proposed implementation of config files
is much simpler and if it is useful, it can be a first step
toward more powerful and convenient driver.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">Thanks,<br>
--Serge<br>
</div>
</div>
<br>
</div>
</div>
<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>