[cfe-dev] Configuration files

[Serge Pavlov via cfe-dev]

Thanks,
--Serge

2017-03-15 23:21 GMT+07:00 Hal Finkel <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 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.

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