[cfe-dev] Configuration files

[Hal Finkel via cfe-dev]

On 03/15/2017 10:59 AM, Serge Pavlov wrote:
> 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 
> <mailto: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.

Right.

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

Can't you just make it configurable? If parsing an `@file`, do the old 
thing, otherwise, do the new thing?

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

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

If that can't be done reasonably, then I think that's okay too. We just 
should understand (and document) why.

  -Hal

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

-- 
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/20170315/2ac020fa/attachment.html>