[cfe-dev] Configuration files

[Serge Pavlov via cfe-dev]

Hi all,

Implementation is presented in https://reviews.llvm.org/D24933. 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.

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:
http://lists.llvm.org/pipermail/cfe-dev/2016-September/050783.html.

Some express concern that this is not a useful feature, the main points are
listed below.

1. Config files vs `@file`
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:
- It searches well-known places for files, while `@file` must search only
the current directory,
- 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.
- Config files may contain comments,
- Options from config file do not produce warning 'unused option' even if
they are indeed unused.

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.

2. More elaborated solutions

Many are of opinion that config file in this form is too primitive
solution, for instance:
- A good solution must be able to deduce target from arguments (-m32),
- 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,
- Config file must reduce complexity of clang driver.

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):

    …
    #if (argv.contains("-m32"))
    -target i686-unknown-linux-gnu
    #else
    -targer x86_64-unknown-linux-gnu
    #endif
    …

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.

Speaking about ways to make clang driver more flexible and less complex, we
need to mention an approach implemented in gcc as `spec files` (
https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html). 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.

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.


Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170206/2414ec40/attachment.html>