Values for define_macros=

[mdavidsaver]

For Extension(defines_macros=[...], ...) the defines_macros list is documented as accepting entries of the form ('NAME','value') and ('NAME',None), which with GCC yield -DNAME=value and -DNAME respectively. I find that a third form ('NAME',) is accepted, yielding -UNAME.

This third form is redundant to the undef_macros=[...] list, with the added benefit of control over relative ordering, which is important as I have a situation where I want to pass -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 in this order to override the default value of that builtin macro.

Is this third form considered supported? If not, can it be?

[agammann]

There is a distinction between the two APIs in the documentation: CCompiler.compile(macros=...) explicitly documents a one-element tuple as an undefinition, but the Extension.define_macros parameter describes two-element definitions and a separate undef_macros list. So the compiler-layer behavior has a documented basis, while the Extension description does not explicitly promise that spelling.

For your GCC-specific ordering requirement, a documented alternative is to keep both flags together in extra_compile_args:

Extension(
    "your_module",
    ["your_module.c"],
    extra_compile_args=["-U_FORTIFY_SOURCE", "-D_FORTIFY_SOURCE=2"],
)

Setuptools puts those extra arguments after its normal compiler options, and GCC processes -D and -U in their supplied order.

I checked setuptools 84.0.0: its preprocessing helper still maps ("_FORTIFY_SOURCE",) to -U_FORTIFY_SOURCE. I also built and imported a C extension with the extra_compile_args approach using GCC 15.2.0; the compile command retained -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2, and the extension reported the final value as 2. These flags are compiler-specific, so use them only for your GCC build configuration.