sepavloff added a comment.
>> 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.
> 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.
> 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. 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.
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.
- most compilers support it, in particular:
- Intel compiler: ICCCFG (https://software.intel.com/en-us/node/522775),
- Keil C compilers: ARMCOMPILER6_CLANGOPT
(http://www.keil.com/support/man/docs/armclang_intro/armclang_intro_chr1374139991387.htm)
- Visual C: CL (https://msdn.microsoft.com/en-us/library/kezkeayy.aspx)
- IBM XL C/C++: XLC_USR_CONFIG
(http://www.ibm.com/support/knowledgecenter/en/SSGH3R_13.1.3/com.ibm.xlcpp1313.aix.doc/compiler_ref/tusetenv1.html)
https://reviews.llvm.org/D24933
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
