[cfe-dev] Configuration files

[Hal Finkel via cfe-dev]

On 03/15/2017 11:21 AM, Hal Finkel via cfe-dev wrote:
>
>
> 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.

To elaborate slightly, we currently support `@file` in Clang by calling 
llvm::cl::ExpandResponseFiles in Clang's driver. Since this is general 
LLVM functionality, and the config-file paring is more Clang-specific, 
maybe this is not worth changing. However, what if we processed `@file` 
like config files, but in a mode which was backward compatible with 
existing `@file` semantics?

  -Hal

>
>  -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
>
>
> _______________________________________________
> 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/20170315/0245648d/attachment.html>