WiFiProv.ino: error: operator 'not' has no right operand

[igrr]

Board

ESP32-S3

Device Description

Just a compilation issue, not relevant

Hardware Configuration

Just a compilation issue, not relevant

Version

other

IDE Name

Arduino IDE 1.8.19

Operating System

not sure

Flash frequency

not sure

PSRAM enabled

no

Upload speed

not sure

Description

in https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFiProv/examples/WiFiProv/WiFiProv.ino:

uncommenting the line #define USE_SOFT_AP as mentioned in the sketch leads to an error:

error: operator 'not' has no right operand

I guess it should be #define USE_SOFT_AP 1 or the ifdefs later in the sketch have to be changed to use ... not defined(USE_SOFT_AP) instead of not USE_SOFT_AP.

Sketch

https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFiProv/examples/WiFiProv/WiFiProv.ino

Debug Message

sketch.ino:65:75: error: operator 'not' has no right operand
 #if CONFIG_IDF_TARGET_ESP32 && CONFIG_BLUEDROID_ENABLED && not USE_SOFT_AP
                                                                           ^
sketch.ino:76:50: error: operator 'not' has no right operand
   #if CONFIG_BLUEDROID_ENABLED && not USE_SOFT_AP
                                                  ^

Error during build: exit status 1

Other Steps to Reproduce

https://wokwi.com/projects/372038262823000065

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

Thanks @igrr! I'll add a PR with the fix.

[SuGlider]

@igrr -
I also noticed that Wokwi doesn't define CONFIG_IDF_TARGET_ESP32, therefore it never starts the BLE Provisioning, although it still prints the BLE QR Code.
This inconsistence doesn't happen when building it with the Arduino IDE.

[SuGlider]

I've just tested the example using the ESP32, ESP32S3 and ESP32C3 + ESP SoftAP Prov Android APP.
All those 3 SoC work fine with BLE provisioning, therefore there is no need to restrict it only to the ESP32.
I'll also commit this change.