sip: Conditionally wrapping a virtual method?

[Scott Talbert]

On Thu, 2 Apr 2026, Phil Thompson wrote:

>> I'm trying to wrap a C++ class in wxPython that has a virtual method
>> that is conditionally defined.  Very simplified, it looks like this:
>> 
>> class wxWindow
>> {
>>     public:
>>         ...other methods...
>> #if wxUSE_ACCESSIBILITY
>>         virtual wxAccessible* CreateAccessible() { return nullptr; }
>> #endif
>> }
>> 
>> It seems like the sip way of doing this would be to use a feature flag
>> and guard this method with %If in the .sip file.  However, wxPython's
>> build process pre-generates all the .cpp code as part of the sdist
>> build process, so the generated .cpp code is used on all platforms,
>> where wxUSE_ACCESSIBILITY is both defined and not.
>> 
>> Is there any way to solve this with sip using a cpp compile time flag?
>> If I include the method unconditionally the .sip file, it fails to
>> compile on platforms where wxUSE_ACCESSIBILITY is not defined because
>> the method is flagged with SIP_OVERRIDE and it doesn't override
>> anything on those platforms.
>
> The design of sip assumes the .sip files are distributed and the .cpp files 
> are just build artifacts. The .sip files are part of an installation and 
> allow 3rd party packages to extend them by %Importing them.
>
> A feature results in a corresponding SIP_FEATURE_* macro to be defined so you 
> could try overriding it on the compiler command line.
>
> You could also try overriding the definition of SIP_OVERRIDE on the command 
> line.

Yes, it's understandable that the expectation is that the .cpp files are 
not part of the sdist and are generated at build time.  However, 
pre-generating them shaves off a few minutes from our already long build 
time.  Presumably that's why Robin set things up this way originally.

I think I'd prefer to avoid overriding SIP_OVERRIDE, too, as that has been 
useful in finding bugs in the past.

How about this - would you be willing to emit #ifdef SIP_FEATURE_XYZ / 
#endif guards around code for enabled features?  Then, features could be 
disabled at compile time, which it seems like it would solve our problem 
and be relatively clean.

Thanks,
Scott