./configure --help should only show how to alter the default behaviour. Thus not articulating explicitly the default on --help, implies that not passing an option to ./configure will not imply that option. See also my article https://ab.bapha.be/posts/help-output/.
With Python 3.15.3 ./configure --help:
--enable-universalsdk[=SDKDIR]
create a universal binary build. SDKDIR specifies
which macOS SDK should be used to perform the build,
see Mac/README.rst. (default is no)
--enable-framework[=INSTALLDIR]
create a Python.framework rather than a traditional
Unix install. optional INSTALLDIR specifies the
installation path. see Mac/README.rst (default is
no)
--enable-wasm-dynamic-linking
Enable dynamic linking support for WebAssembly
(default is no)
--enable-wasm-pthreads Enable pthread emulation for WebAssembly (default is
no)
--enable-shared enable building a shared Python library (default is
no)
--enable-profiling enable C-level code profiling with gprof (default is
no)
--disable-gil enable experimental support for running without the
GIL (default is no)
--enable-pystats enable internal statistics gathering (default is no)
--enable-optimizations enable expensive, stable optimizations (PGO, etc.)
(default is no)
--enable-bolt enable usage of the llvm-bolt post-link optimizer
(default is no)
--enable-loadable-sqlite-extensions
support loadable extensions in the sqlite3 module,
see Doc/library/sqlite3.rst (default is no)
--disable-test-modules don't build nor install test modules
--without-static-libpython
do not build libpythonMAJOR.MINOR.a and do not
install python.o (default is yes)
and more…
--disable-test-modules is used as I suggested. --disable-gil should be renamed to --enable-gil. All (default is no) and (default is yes) should be removed, when the option is binary (on/off/yes/no/with/without/enabled/disabled).
When a parameter has many possible values, sometimes --help emits =[ and sometimes [=. This is inconsistent:
--enable-big-digits[=15|30]
use big digits (30 or 15 bits) for Python longs
(default is 30)]
--with-pkg-config=[yes|no|check]
use pkg-config to detect build options (default is
check)
Would a reasonable next step be to confirm which parts of the ./configure --help output we’d like to standardize or clarify?
From the thread, it looks like the main issue is inconsistency in default value formatting (e.g., “(default=yes)” vs “default: yes”) and missing defaults for some flags. I can start by listing the current variations and proposing a normalized pattern before implementing it in configure.ac and regenerating the help text.
Does that sound like the right direction, or is there a preferred precedent for help output formatting from other core scripts?
Activity
cyrusradfar commented on Oct 12, 2025
👋🏽I'd like to work on this.
Would a reasonable next step be to confirm which parts of the ./configure --help output we’d like to standardize or clarify?
From the thread, it looks like the main issue is inconsistency in default value formatting (e.g., “(default=yes)” vs “default: yes”) and missing defaults for some flags. I can start by listing the current variations and proposing a normalized pattern before implementing it in configure.ac and regenerating the help text.
Does that sound like the right direction, or is there a preferred precedent for help output formatting from other core scripts?