[FR] Add the ability for an extension to be compiled to a .o but not linked into a .so

What's the problem this feature will solve?

I'm attempting to build a single extension module that's a combination of Rust code and CFFI-generated C code. This is described in some detail in https://github.com/pyca/cryptography/issues/6634

But in short, the first objective is to get a .o with the compiled C code, which I will then be responsible for linking into the Rust extension module.

Unfortunately setuptools/distutils doesn't have an easy way to do only this. The core logic that compiles things to .o files and then links them is at: https://github.com/pypa/setuptools/blob/main/setuptools/_distutils/command/build_ext.py#L487-L561 Removing the link_shared_object invocation can only be done by copy-pasting the majority of this code.

Describe the solution you'd like

An option on Extension, which is then used in build_ext, which instructs setuptools/distutils to compile the .o files, but not build a .so (and not try to install the .so).

Alternative Solutions

The alternate solution is to override build_ext with a copy-paste of the majority of build_extension's code. This is sub-optimal due to the large amounts of copy-paste required, and also because of the complexity of introducing it into the right place in the class heirarchy, because cffi itself relies on overriding build_ext (https://foss.heptapod.net/pypy/cffi/-/blob/branch/default/cffi/setuptools_ext.py#L145)

Additional context

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct

Start in setuptools/_distutils/command/build_ext.py, especially the build_extension logic around lines 487–561, and trace how Extension objects reach compilation, link_shared_object, and installation. Define the Extension option and build_ext behavior so the C sources produce .o files without creating or installing a .so; the issue’s Rust/CFFI use case is the completion check.