<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Thanks,<br>--Serge<br></div></div>
<br><div class="gmail_quote">2017-03-15 23:21 GMT+07:00 Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    <p>On 03/15/2017 10:59 AM, Serge Pavlov
      wrote:<br></p>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_extra">
          <div>It looks like the features that may be added to the
                file format in `@file` construct without disturbing
                existing functionality are:<br></div></div></div></blockquote></span><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
              <div><span class="gmail-m_-5995033795877453493gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>-
                comments,</div>
              <div><span class="gmail-m_-5995033795877453493gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>-
                splitting long lines with trailing '\',</div>
              <div><span class="gmail-m_-5995033795877453493gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>-
                suppressing warnings on unused options.</div>
              <div>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.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Can't you just make it configurable? If parsing an `@file`, do the
    old thing, otherwise, do the new thing?<span class="gmail-"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>
              <div><br>
              </div>
              <div>Configuration encoded in compiler file name, as in
                `armv7l-clang` is not related to `@file`, so this
                functionality implemented in <a href="https://reviews.llvm.org/D24933" target="_blank">https://reviews.llvm.org/<wbr>D24933</a>
                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:</div>
              <div>- 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.</div>
              <div>- 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.</div>
              <div><br>
              </div>
              <div>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.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    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)?<br>
    <br>
    If that can't be done reasonably, then I think that's okay too. We
    just should understand (and document) why.<span class="gmail-HOEnZb"><font color="#888888"><br>
    <br></font></span></div></blockquote><div><br></div><div>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 (<a href="https://reviews.llvm.org/D24926">https://reviews.llvm.org/D24926</a>, 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.</div><div><br></div><div>Thanks,</div><div>--Serge</div></div></div></div>