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
