[PATCH] D24933: Enable configuration files in clang

[Hans Wennborg via cfe-commits]

hans added a comment.

In https://reviews.llvm.org/D24933#591943, @sepavloff wrote:

> >> Default config file is searched for only in the directory where clang executable resides. It allows SDK suppliers to customize compiler, for instance by turning off unneeded warnings, by providing their own clang.cfg. On the other hand developers cannot by accident override default setting because clang.cfg is placed in system directory.
> > 
> > I thought one of the stated goals for this patch would be to allow users to set default flags without touching the project's build system.
>
> Yes, that's true. Initially it was supposed that a user can override compiler defaults by putting `clang.cfg` into well-knows places, including `~/llvm`, in particular. Then this idea was rejected as a result of feedback, and default config file now is allowed only in the directory where `clang` executable resides. It still allows to override default settings by SDK suppliers but limit this possibility to powerful users.


I see. The SDK use case seems quite reasonable to me.

>> What about this line?
>> 
>>   static const ArrayRef<const char *> SearchDirs({ "~/.llvm", "/etc/llvm" });
>> 
>> That sounds like you'll be searching the home directory for a default config file.
> 
> These are directories where config files specified by option `--config` are searched for. There is a big difference between default config files and those specified explicitly. Default file adds option silently, user does not specify anything in the command line. Due to this point it can represent a source of troubles, such as problems with bug reports. In contrast the named config files are specified explicitly in clang invocation. A user may set the same set of option by listing them in command line. Such config file does not represents any dander, it is only a convenience feature.

Oh, I misunderstood then. Thanks for clarifying.

>> And even if we ignore that, the CLANGCFG environment variable presents the same problem.
>> 
>> Let's say a developer uses that to point to a config file with their favourite compiler flags for compiling on their x86_64 machine.
>> 
>> But then they want to build something using the Android NDK, whose Clang will now pull in that config file and start passing flags which doesn't apply to the target, e.g. ARM. The user might not even be invoking the NDK directly; it might be through Android Studio which certainly doesn't expect other flags to be used than the ones it passes.
> 
> If a user forget to update LIBRARY_PATH or C_INCLUDE_PATH the result would be the same.

I don't like those either :-)

> Config file set by environment variable is similar to default config file as user does not specify anything in command line. But the user must explicitly specify the file, it is not made automatically.

Sorry, I don't understand this part.

> Ability to append compiler options via environment variable is important feature, I think, because:
> 
> - This feature implemented by Intel compiles has proven its convenience.
> - Build systems provided by software components are not perfect. Some do not honor CFLAGS, some require setting options inside makefiles etc. Changing compiler options might be a challenge. Environment variable solves this problem easily and effectively.

But now you seem to be serving the goal about letting the user set flags without using the build system, which I thought wasn't a goal anymore?

Again, allowing SDKs to configure the compiler (such as setting the default target) without actually changing it in the source seems somewhat reasonable, but this other part worries me.


https://reviews.llvm.org/D24933