[cfe-dev] Configuration files

Tue Mar 14 12:08:59 PDT 2017

On 02/06/2017 10:05 AM, Serge Pavlov via cfe-dev wrote:
> 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.

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

>
> 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.

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.

In any case, I definitely consider this follow-up work.

Thanks again,
Hal

>
> 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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170314/ffbd845b/attachment.html>