hans added a comment.
In https://reviews.llvm.org/D24933#590493, @sepavloff wrote:
> > For Chromium, our build system provides a specific Clang version close to
> > ToT, and obviously what flags to use when invoking it. (Developers can of
> > course override the flags when configuring if they want.) Now maybe a
> > developer has a ~/clang.cfg because they want certain flags on by default
> > when they build *other* projects, those flags would now be applied to all
> > clangs, including the one we provide, and potentially wreak havoc.
>
> 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.
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.
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.
https://reviews.llvm.org/D24933
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
