[cfe-dev] Configuration files

[Serge Pavlov via cfe-dev]

Hi Hal,

Thank you very much for your interest and help!

2017-03-15 2:08 GMT+07:00 Hal Finkel <hfinkel at anl.gov>:


> 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).
>
>
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. It
looks like the features that may be added to the file format in `@file`
construct without disturbing existing functionality are:
- comments,
- splitting long lines with trailing '\',
- suppressing warnings on unused options.
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.

Configuration encoded in compiler file name, as in `armv7l-clang` is not
related to `@file`, so this functionality implemented in
https://reviews.llvm.org/D24933 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:
- 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.
- 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.

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.


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

 This was a bad example. To obtain more powerful solution clang need
something like gcc spec files. This is completely different topic.

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