[PATCH] D133325: [Driver] Allow search of included response files as configuration files

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff marked 4 inline comments as done.
sepavloff added a comment.

In D133325#3771275 <https://reviews.llvm.org/D133325#3771275>, @MaskRay wrote:

> For a config file, `--search-config-dirs` is introduced to change how `@cfg` is resolved
> (relative to `--config-system-dir` or `--config-user-dir=`).
> I think mentioning the option names in the summary and having an elaborated example in `clang/docs/UsersManual.rst` will help.

Added simple example in `clang/docs/UsersManual.rst`.

>> This change implements option --search-config-dirs, which modifies the search algorithm, - files included by @file are searched for as configuration files, in the same directories, and can be overridden by a user.
>
> Is the previous search algorithm sensible? If we think not, we can change the default, and introduce a driver or CC1 option to stay the old behavior.
> My reasoning is that I cannot imagine many cases which can be broken by changing the search algorithm.

There is nothing wrong with the previous algorithm, it is just for a different use case. For example, some users prepare set of config files, which contain set of options for various tasks, and put them to directories, which are easy to access (like `~/p1/dbg.cfg`). There files may share bulky information like include paths by using `@file` directives. Another directory may contain set of configuration files, say, for different platform. Enforcing the new algorithm would break existing work environments and require additional efforts to restore functionality.

One of the use case for the new algorithm is described in the patch description. As the option `--search-config-dirs` may be specified inside config file, from user perspective nothing changes, they just specify config file with the option `--config`, as previously. Compatibility is not broken.

> I think I'm still confused why we need a new option for changing the search algorithm.
>
> Say, we have `--config-system-dir=system --config-user-dir=user` and three files `system/a.cfg`, `system/b.cfg`, `user/b.cfg`.
> `system/a.cfg` contains `@b`.
> The old algorithm resolves to `system/b.cfg` (relative to the dir of `system/a.cfg`: `system/`) while the new algorithm resolves to `user/b.cfg`?

You are right. It simplify preparing working environment by combining its parts (include paths, libraries, preprocessor definitions etc) taken from well-knows place, still allowing a user to modify it without need to copy all environment into a new directory and then changing it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133325/new/

https://reviews.llvm.org/D133325