One example would be if a site had some coding standards and wanted to use some -W options to enforce them.
I don’t find that a compelling use case. Coding standards tend to be project specific and are therefore best enforced via the build system(s) used for each project.
It is quite common with our customers that they want to be able to control this kind of stuff at the installation level. They either have one very large project or multiple projects they want to follow the same standards.
It is quite common with our customers that they want to be able to control this kind of stuff at the installation level. They either have one very large project or multiple projects they want to follow the same standards.
I don’t doubt that at all; I’m aware of the xlc.cfg, vacpp.cfg, and similar files and I don’t doubt that customers modify them. But I think that is a pattern that should not be encouraged in upstream Clang as it creates difficulties for project build systems; they can’t tailor their configuration to a given compiler particularly well if the behavior of the compiler changes on a site-by-site basis. I have no concerns with IBM implementing such behavior in its Clang distributions of course.
For the record, Gentoo’s support for choosing between runtimes would also benefit from this. Right now users have to rebuild clang to change the values of -DCLANG_DEFAULT.... I think it’d be much better if we could just drop a /etc/clang/clang.cfg and control the default runtimes there.
This change was proposed at ⚙ D109621 [clang][Driver] Default to loading clang.cfg if config file not specified.
@MaskRay has made some good progress on the gcc-config bits and happy to move forward on that from the Gentoo side.
For distributions, however, it is rather compelling if we want to trial making something more strict (possibly on behalf of LLVM itself, see e.g. Configure script breakage with the new -Werror=implicit-function-declaration), or like -Werror=format-security.
It’s also something distributions kind of have already for GCC via spec files (and in Gentoo, we had/have some stuff to make it easy to switch between them). Having an analogue for Clang would be most helpful.
This would also be helpful for forcing things like #include <stdc-predef.h> (see 870001 – sys-devel/clang: doesn't include <stdc-predef.h> (dev-libs/libedit: fails to compile with Clang 15 (and musl?) (error: wchar_t must store ISO 10646 characters))).
I support this proposal.
I originally thought this would add yet another nuance for developers to analyze user reports, but then I realize we have to admit vendor customizations.
(GCC provides a lot of --enable-* and every Linux distro may do something differently.)
(
In the initial thread discussing configuration files Configuration files ,
Joerg expressed strong concern of a magic user default (but he thought a system default was fine).)
Currently there are bunch of cmake variables customizing the Clang behavior:
And new variables are coming (e.g. default stack protector level). Many of them can be overridden by a driver option.
A default configuration file location can possibly render a lot above unneeded.
Per Clang Compiler User’s Manual — Clang 16.0.0git documentation , a vendor can make clang a shell script which executes
a {prefix}-clang and let {prefix}-clang load {prefix}.cfg. So if a vendor wants to have a default configuration file,
there is already a way. (Options in a configuration file are not subject to -Wunused-command-line-argument.)
This proposal will make the use less hacky for some vendors.
Some random opinions:
For the default configuration file location, one idea is to use $resource_dir/etc as the directory.
Downstream clang tools need to know the resource directory but may not know the executable path.
We have GCCMode, GXXMode, CPPMode, CLMode, FlangMode, DXCMode.
Perhaps each mode should load different configuration files. (clang++.cfg perhaps doesn’t help users doing clang --driver-mode=g++)
It looks like the same effect as default config file can be obtained if clang would try to load two config files, the first one deduced from driver mode (clang.cfg, clang++.cfg, gcc.cfg etc) and the second - defined by target prefix. The driver mode file could set some default values, which may be overridden in target-prefix file. The driver mode file works as default config file.
This solution has some advantages over simple default config file:
@file constructs.To get invocation without loading config files, a new option is required. In some cases such invocation is necessary and solution for this task must exist.
I suppose the most complete solution would involve something like:
<prefix>-<mode>.cfg first.<prefix>.cfg and <mode>.cfg.However, I’m not sure if we should have two bases for fallback from missing prefix file and for fallback from missing mode file, or some other model.
Personally, I don’t think I need all that but I can see potential use cases e.g. for specifying host-specific options, as well as mode-specific options.
We also need to use that in the test suite. Otherwise, if we enable the system config location during the builds, user’s configuration may impact the test results.
We already have CLANG_CONFIG_FILE_SYSTEM_DIR, though for some reason isn’t it a cache variable. I think it’d be useful to have some default at least for unix derivatives, so that users wouldn’t end up being confused by every Linux distribution choosing their own directory.
As mentioned on the Phab review too - as for default-included config files, it would be great to have it look for e.g. <triple>.cfg too, if clang is invoked as clang -target <triple>. Currently this is done if clang is invoked via a symlinked name such as <triple>-clang, but not if the triple is set explicitly on the command line. (This would be very helpful wrt setting defaults like CLANG_DEFAULT_RTLIB and CLANG_DEFAULT_CXX_STDLIB etc, where you may want to have such defaults set for cross targets but not when operating as native compiler.)
Yes I have suggested this before - I think that would be very helpful for cross-compile toolchains.
I’ve submitted ⚙ D134018 [clang] [Driver] Add an option to disable default config filenames to add a --no-default-config option. Hopefully that’d help moving things forward.
@mgorny has commandeered ⚙ D109621 [clang][Driver] Default to loading clang.cfg if config file not specified to add the support. Thanks for stepping up!
Cc some folks @davidchisnall @reinterpret_cast @rengolin @rnk from Configuration files for attention.
To be honest, I’ve only done the absolute minimum to make the current config useful for vendors, and covering the proverbial 99% of use cases, i.e. unless I’m mistaken, it makes it possible to install matching config files for all clang symlinks we install.
There are many things I dislike about the current logic, I’m not sure how much of that can be changed without breaking backwards compatibility (and whether we even need to worry about it) and I honestly doubt I want to be rewriting it.
The things I dislike that I’ve observed so far are, in no particular order:
clang --driver-mode=... does the wrong thing, so does clang --target=....-m32 that substitutes arch name in prefix.x86_64-clang++.cfg in system dir overrides x86_64.cfg in user dir. Not sure if it shouldn’t be the other way around.Ok, I think I’ve hit my first roadblock so far: discontinuity between options supported by various clang drivers.
So far we’ve considered using the following options in the system config file:
-fuse-ld, -rtlib, -stdlib, -unwindlib to control the default runtimes used by clang--gcc-install-dir proposed in D133329 to supply the GCC installation directory externally and make it possible to remove custom Gentoo logic from Driver-Werror=... and -Wno-error=... to aid investigating regressions with new clang versions (per Configure script breakage with the new -Werror=implicit-function-declaration - #39 by mgorny; this isn’t that important though)Right now setting these options in the main configuration file means that a variety of driver invocations will fail due to incorrect options. To be honest, I don’t think that it’s really a good solution to require users to supply two dozen configuration files for various driver mode-target combinations to make sure every one gets the right set of options. I see two potential solutions here. Either:
To be honest, I think 1. seems more correct but I’m happy enough with either option. On top of that, I think it would also make sense to add an option like --verify-config that disables the “unknown option silencing” behavior of config parsing, to let users check if their configs are valid.
If clang searched for two config files, one for target and one for driver mode, could it reduce number of configuration files in your use case?
Yes, that would be helpful. However, FWIU we currently allow only a single configuration file, don’t we?
If we went that way, we should also probably improve the logic to respect the actual target and actual driver mode independently of the executable name. I’m not sure how much backwards compatibility we need, though.
Yes, but there are demands for more flexible solution for configuration file from several users, so it would be nice to improve existing mechanism.
Allowing two config files probably leads to support of two --config options or using some other way to specify target and driver config files separately. This option is used to bypass file search mechanism, which might be complex, and we need something similar in any case.
If you could work on that, that’d be most helpful. I’m afraid my time is limited (and I’ve already spent too much on it), yet given the need of testing changes prior to Clang 16.x release, it’d nice to have some working solution ASAP. Hence, my patch. However, OTOH I wouldn’t want people to start relying on it if the final config support is going to be different.
Hmm, maybe here’s a better description of what we would like to have.
Basically, we’d like to have something like gentoo-runtimes.cfg with the equivalent of:
-fuse-ld=...
-rtlib=...
-stdlib=...
-unwindlib=...
and gentoo-gcc-install.cfg:
--gcc-install-dir=...
and we’d like to be able to reasonably include these configs so that they would be appropriately picked up by all clang invocations.