Disable warnings as errors

apalazzi
Posts: 9
Joined: Sun Aug 17, 2025 6:28 pm

Disable warnings as errors

Postby apalazzi » Sun Sep 21, 2025 8:21 pm

Hi,

I'm having this extremely annoying issue where esp-idf forces down my throat its compiler warnings as errors. In the specific case I have

error: 'virtual void Motor::run()' was hidden [-Werror=overloaded-virtual=]

I tried to disable this behaviour (together with setting my own flags) in the root CMakeLists.txt:

Code: Select all

idf_build_set_property(COMPILE_OPTIONS "-Wall" APPEND)
idf_build_set_property(COMPILE_OPTIONS "-Wextra" APPEND)
idf_build_set_property(COMPILE_OPTIONS "-Wpedantic" APPEND)
idf_build_set_property(COMPILE_OPTIONS "-Weffc++"  APPEND)
idf_build_set_property(COMPILE_OPTIONS "-Wno-error=all"  APPEND)
However the problem is still there, moreover this sets the flags for all the files, including IDF components, compilation is slow as hell because of the thousands of warnings, and sometime the components themselves fail to compile.

Same result if I try to fix it in the main/CMakeLists.txt like this:

Code: Select all

target_compile_options(${COMPONENT_LIB} PRIVATE "-Wall" "-Wextra" "-Wpedantic" "-Weffc++" "-Wno-error=all")
 
So, how do I set the compiler flags that I want so that my code is compiled according to my warning/error policy and not the one that IDF is using?

Bye
Andrea

MicroController
Posts: 2663
Joined: Mon Oct 17, 2022 7:38 pm
Location: Europe, Germany

Re: Disable warnings as errors

Postby MicroController » Tue Sep 23, 2025 9:15 am

I suggest to fix the cause(s) of the warning(s)/error(s) instead of disabling it (e.g. https://twdev.blog/2024/07/cpp_overloaded_virtuals/).

If you "need" a certain construct which gives a warning/error, you can selectively control the warning behavior for that piece of code via gcc's Diagnostic Pragmas.

apalazzi
Posts: 9
Joined: Sun Aug 17, 2025 6:28 pm

Re: Disable warnings as errors

Postby apalazzi » Tue Sep 23, 2025 11:49 am

I suggest to fix the cause(s) of the warning(s)/error(s) instead of disabling it (e.g. https://twdev.blog/2024/07/cpp_overloaded_virtuals/).

If you "need" a certain construct which gives a warning/error, you can selectively control the warning behavior for that piece of code via gcc's Diagnostic Pragmas.
Sorry, but this answer is not useful at all. Sure I will fix my bugs, but there's no reason on earth why I should follow ESP's warning/error policy and not my own.

Just as an example, when I enable -Weffc++ I have a massive amount of warnings on ESP's code, and if my policy is to enable -Werror for zero warnings on release - but not on development - then I'll have to fix IDF's own error or modify my policy. I hope you agree that both solutions are suboptimal to say the least, and I don't see any solid reason to force that on the users.

The right solution is to compile the IDF files with the flags and policy that IDF decides are the best, and let other developers chose their set of flags and policies on their files, not to enforce your policy to everyone.

Try this, if you're not convinced:

Code: Select all

// main.cpp
#include <stdio.h>
#include <stdbool.h>
#include <unistd.h>
#include "Arduino.h"

extern "C" void app_main(void)
{
    while (true) {
        printf("Hello from app_main!\n");
        sleep(1);
    }
}
project cmake:

Code: Select all

cmake_minimum_required(VERSION 3.5)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(app-template)
main cmake:

Code: Select all

# See the build system documentation in IDF programming guide
# for more information about component CMakeLists.txt files.

idf_component_register(
    SRCS main.cpp         # list the source files of this component
    INCLUDE_DIRS        # optional, add here public include directories
    PRIV_INCLUDE_DIRS   # optional, add here private include directories
    REQUIRES            # optional, list the public requirements (component names)
    PRIV_REQUIRES       # optional, list the private requirements
)

target_compile_options(${COMPONENT_LIB} PRIVATE "-Werror"  "-Wall" "-Wextra" "-Wpedantic" "-Weffc++" "-O3" "-std=c++23" )
Seems quite basic to me, but it will fail to build. And if you're telling me that I have to change my policy to match IDF's, then sorry but i strongly disagree, and there's nothing to discuss further unless you bring a real solution.

Bye
Andrea
Last edited by apalazzi on Thu Sep 25, 2025 5:23 pm, edited 1 time in total.

MicroController
Posts: 2663
Joined: Mon Oct 17, 2022 7:38 pm
Location: Europe, Germany

Re: Disable warnings as errors

Postby MicroController » Tue Sep 23, 2025 4:02 pm

but there's no reason on earth why I should follow ESP's warning/error policy and not my own.
Some might see being compatible with the SDK you're using as a reason. Some might say that there's no reason on earth why your code should be producing warnings in the first place.
and there's nothing to discuss further unless you bring a real solution.
So you already know that you actually should change your workflow...
I'm sure someone else will bring you a real solution soon enough then.

apalazzi
Posts: 9
Joined: Sun Aug 17, 2025 6:28 pm

Re: Disable warnings as errors

Postby apalazzi » Tue Sep 23, 2025 5:44 pm

but there's no reason on earth why I should follow ESP's warning/error policy and not my own.
Some might see being compatible with the SDK you're using as a reason. Some might say that there's no reason on earth why your code should be producing warnings in the first place.
Being compatible with a SDK should not mean being restricted to a certain set of warnings and ignore others. And if there's no reason to produce warnings, why have warnings at all, and even more treat them as errors? Are people at GCC dumb for adding -Weffc++ warinings? Is being strictly adherent to the C++ standard with -Wpedantic wrong?
So you already know that you actually should change your workflow...
Read again: I never said that.
I'm sure someone else will bring you a real solution soon enough then.
At leas I hope nobody else will come here to preach on other people policy and compilation flags.

Bye
Andrea

vvb333007
Posts: 71
Joined: Wed Jul 31, 2024 5:53 am
Location: Thailand
Contact:

Re: Disable warnings as errors

Postby vvb333007 » Thu Sep 25, 2025 3:24 am

If you want to use your own policy, just add #pragma which disables warnings.
Since you are goiing to fix them anyway, this temporary solution (#pragma) is ok.

In general, if you are developing something using SDK the general rule is to use their constraints. Probably they are there for a reason.
Thanks!
Slava.

vvb333007
Posts: 71
Joined: Wed Jul 31, 2024 5:53 am
Location: Thailand
Contact:

Re: Disable warnings as errors

Postby vvb333007 » Thu Sep 25, 2025 3:53 am


Seems quite basic to me, but it will fail to build. And if you're telling me that I have to change my policy to match IDF's, then sorry but i strongly disagree, and there's nothing to discuss further unless you bring a real solution.

Bye
Andrea
You forgot to add "#" at the very beginning. May be this is why it fails to build.
Thanks!
Slava.

apalazzi
Posts: 9
Joined: Sun Aug 17, 2025 6:28 pm

Re: Disable warnings as errors

Postby apalazzi » Thu Sep 25, 2025 5:25 pm


Seems quite basic to me, but it will fail to build. And if you're telling me that I have to change my policy to match IDF's, then sorry but i strongly disagree, and there's nothing to discuss further unless you bring a real solution.

Bye
Andrea
You forgot to add "#" at the very beginning. May be this is why it fails to build.
That was just a copy/paste error (fixed). Try it now, on my PC it fails while building the Arduino libraries.

Bye
Andrea

apalazzi
Posts: 9
Joined: Sun Aug 17, 2025 6:28 pm

Re: Disable warnings as errors

Postby apalazzi » Thu Sep 25, 2025 5:37 pm

If you want to use your own policy, just add #pragma which disables warnings.
Since you are going to fix them anyway, this temporary solution (#pragma) is ok.

In general, if you are developing something using SDK the general rule is to use their constraints. Probably they are there for a reason.
You seem to have missed the point: I don't want to disable warning, in fact I want to enable more warnings than the ones that ESP is using; I just want them not to be errors. The problem is that then those warnings are also applied to ESP libraries, which leads to compilation error on ESP own library components because now more warnings are treated as errors.

I agree that the warnings they're enabling are there for a reason, but it's their subjective opinion on which warnings should be enabled and which one should be treated as errors: otherwise why compilers have more warnings that can be enabled if this were the perfect set of warnings?
Pretending that everybody in the world using their chip must use their own subjective set of warning/error flags is just not right, if I were doing this for a living I would switch to another chip for my work. And in fact I'm considering switching to another chip even for my hobbyist projects.

Bye
Andrea

vvb333007
Posts: 71
Joined: Wed Jul 31, 2024 5:53 am
Location: Thailand
Contact:

Re: Disable warnings as errors

Postby vvb333007 » Sun Sep 28, 2025 4:03 am

I just want them not to be errors. The problem is that then those warnings are also applied to ESP
Then, search and replace all -Werror occurences with what you think is appropriate. May be -Wall.
This is what I do when I need to change compiler/linker flags in Arduino environment, e.g. specify -Wl,wrap linker flags, or change optimizer from Os to O2, or enable all warnings.

BTW if you are talking about SPECIFIC warnings, not just all of them, then use #pragma to promote errors back to warnings:

For example:
#pragma GCC diagnostic warning "-Wunused-variable"
Thanks!
Slava.

Who is online

Users browsing this forum: Amazon [Bot], Barkrowler and 7 guests