[cfe-dev] Configuration files

[Hal Finkel via cfe-dev]

On 03/15/2017 12:04 PM, Serge Pavlov wrote:
>
>
> Thanks,
> --Serge
>
> 2017-03-15 23:21 GMT+07:00 Hal Finkel <hfinkel at anl.gov 
> <mailto:hfinkel at anl.gov>>:
>
>     On 03/15/2017 10:59 AM, Serge Pavlov wrote:
>
>>     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 <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.
>
>
> I understood the question as "can we load config files with @file not 
> with new option", there were such opinions in this thread above. If 
> the question is only about enhancements to processing of `@file`, the 
> reply is yes. In the LLVM part of this patch config file parsing in 
> implemented on top of `@file` processing 
> (https://reviews.llvm.org/D24926, function `cl::tokenizeConfigFile`). 
> It seems to me that comments and using '\' to glue lines may be 
> enabled in `@file` as well, as an extension. Other features may be 
> enabled for config files only but clang must somehow know that the 
> file contains configuration.
Sounds good. I'll look at the patches.

  -Hal

>
> 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/1bf29adf/attachment.html>