sysconfig should export all the information required to build extensions.
The new API should try to expose the information in a compiler-agnostic way.
We should probably still keep sysconfig.get_config_vars(), as an escape hatch, but what should we do to get the users to move to the new API? Perhaps just put a warning on the docs, mentioning the data is essentially unstable?
- Extension suffixes
- definition: See PEP 3149
- consideration: PEP 3149 only defines the names for POSIX
- Windows and other platforms still seem to follow it mostly (refer to
packaging.tags's implementation) - Windows
- Windows and other platforms still seem to follow it mostly (refer to
- design: The API should identify the different extensions types (interpreter, stable abi, none)
- consideration: PEP 3149 only defines the names for POSIX
- currently:
importlib.machinery.EXTENSION_SUFFIXES,sysconfig.get_config_var('EXT_SUFFIX'),sysconfig.get_config_var('SHLIB_SUFFIX')
- definition: See PEP 3149
- Is a shared
libpythonavailable? What's its name? Location?- definition: Yes if built with
--enable-shared - currently:
- (available?)
bool(sysconfig.get_config_var('LDLIBRARY')) - (name?)
sysconfig.get_config_var('LDLIBRARY') - (location?)
sysconfig.get_config_var('LIBDIR')
- (available?)
- definition: Yes if built with
- Is a static
libpythonavailable? What's its name? Location?- definition: Yes unless built with
--without-static-libpython - currently:
- (available?)
bool(sysconfig.get_config_var('LIBRARY')) - (name?)
sysconfig.get_config_var('LIBRARY') - (location?)
sysconfig.get_config_var('LIBDIR')
- (available?)
- definition: Yes unless built with
- Should extensions link against
libpython?- definition: Yes on Android and Cygwin, no everywhere else (see GH-65735)
- currently:
bool(sysconfig.get_config_var('LIBPYTHON'))
- Is it a debug build?
- definition: Yes if built with
--with-pydebug - currently:
bool(sysconfig.get_config_var('Py_DEBUG'))
- definition: Yes if built with
- C flags needed when using the C API
- definition:
-fwrapv(until GH-96821)- Currently, we have unsafe code, and for a lack of a better option we assume it made into C macros, so extensions that use the C API should use
-fwrapv.
- Currently, we have unsafe code, and for a lack of a better option we assume it made into C macros, so extensions that use the C API should use
- definition:
- what else? please comment...
"definition" sections list the answer, if a question, or the value(s) of the item. "currently" sections list the current way of fetching the information.
This is list is a work in progress. Currently, we need to gather all the information that is required to build extensions. If you see anything that's missing, please comment!
- Vendor
CFLAGSandLDFLAGS- I know how much sense this makes, but on some systems, extensions might need certain
CFLAGS/LDFLAGS
- I know how much sense this makes, but on some systems, extensions might need certain
TBD
In certain scenarios, it might make sense to allow venders
- Allow vendors to override "Should extensions link against
libpython?"- Is it wort
https://discuss.python.org/t/building-extensions-modules-in-a-post-distutils-world/23938
Would you consider updating sysconfig's CLI to be in scope?
Currently we ship a separate executable called
python-config, which is a pain to keep in sync withpython(when you havepython3-config,python3.11-configetc.). Couldpython -m sysconfigaccept all the options frompython-config, becoming a drop-in replacement?