On Mon, Nov 17, 2025 at 12:09 AM Sam James <[email protected]> wrote: > > Lewis Hyatt <[email protected]> writes: > > > Hello- > > > > This patch makes it easier to disable a specific language, which is a need > > that comes up from time to time. I have tested it by trying a variety of > > combinations of --enable-languages arguments on the following platforms: > > > > x86_64-linux-gnu > > x86_64-pc-cygwin > > x86_64-w64-mingw32 > > aarch64-apple-darwin24 > > aarch64-redhat-linux (cfarm185) > > ppc64le-redhat-linux (cfarm135) > > riscv64-linux-gnu (cfarm95) > > sparcv9-sun-solaris2.11 (cfarm216) > > mips64-unknown-openbsd7.7 (cfarm231) > > > > The syntax used in this patch is like: > > > > --enable-languages=all,^xyz,^abc > > > > to disable xyz and abc. (If I understand correctly, something like > > > > --disable-languages=... > > > > is not naturally supported by autoconf.) > > > > I considered also using '!' rather than '^', which seems fine too, although > > more problematic as far as shell quoting. I thought '^' might be a good > > choice, being familiar to git users. It would be easy enough to allow '!' > > instead or in addition, or some other syntax. > > > > One thing that wasn't clear was what should be the meaning of, say, > > > > --enable-languages=^abc,^xyz > > > > with all languages specified in the disabled sense. Currently, a blank > > --enable-languages argument leads to an error, while omitting the option > > entirely implies --enable-languages=default. I wasn't sure if > > --enable-languages with all negative entries should implicitly subtract from > > default, subtract from nothing, or be an error. I ended up deciding that > > subtracting from default would be confusing, because it could lead to a > > situation where adding to the argument resulted in fewer languages being > > built, so at least in this patch, --enable-languages=^abc,^xyz just enables > > no languages, which results in building only the minimal required ones, some > > subset of c,c++,lto depending on --enable-bootstrap and --enable-lto. > > > > Please let me know what you think, would this or something along these lines > > would be a good addition? Thanks! > > I can't approve it, but just wanted to say that the implementation looks > good to me, and I support the idea. > > There was some discussion on having 'tiered languages' which we may want > to extend it to in future: > https://inbox.sourceware.org/gcc/[email protected]/ > > > [...] > > sam
Thanks, Sam! Sure, on top of the changes proposed here, adding some new keywords that lie in between "default" and "all" would not be hard at all; certainly not as hard as deciding on the names and which languages go with them :). -Lewis
