sepavloff added a comment. > 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. > As for compiler bugs getting harder to reproduce, we already get a lot of bug > reports where only the driver invocation is provided, e.g. "clang -O2 foo.c". If `foo.c` includes other files, it can be a challenge now. `clang -v` can help but anyway, this task indeed becomes a bit more complex. > Do we want to get the same config file for "clang", "clang++" and "clang-cl"? > They accept different flags. The driver is still the same, so I think we can use the same config file in these cases. Using --driver-mode as a second dimension would make the scheme awkward, IMHO. > Maybe it'd be better to take a step back and attempt to create a regular, > .ini/.conf-style configuration file. One particular advantage of that is that > we can precisely decide which options to support and how to support them. I > think this could be better both for opponents of 'free configuration' (since > it will be less powerful and more controlled), and for proponents of nice > configuration files (such as me). Advanced config file format is a nice idea, but it already got objections in mail list: > because then we will have to document and maintain the semantics of things > like multiple configuration files, in what order they override each other, > and how they interact with flags. Our command line flag logic is already too > complicated. We have one public interface, and it's flags, and I'm hesitant > to add a new one. I think many things can be simpler if we had enough powerful description language, as gcc spec. As for particular concern of making config files less powerful, maybe we could do simple validation of options contained there? For instance, only options started from `-W`, `-I`, etc are allowed, other would cause warning. This however complicates the driver and requires documenting intended behavior. https://reviews.llvm.org/D24933 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
