-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Please correct the order in which the compiler flags are compiled? #11087
-
Board
Arduino Nano ESP32
Device Description
N/A
Hardware Configuration
N/A
Version
latest master (checkout manually)
IDE Name
Arduino IDE 2.3.4
Operating System
Windows 11
Flash frequency
N/A
PSRAM enabled
yes
Upload speed
115200
Description
Hello,
can you please correct the order in which the compiler flags are compiled?
It has always been common that you can change the compilation for yourself using platform.local.txt.
For this you normally use compiler.cpp.extra_flags Unfortunately, this is not possible with the ESP32 Core Package
because you have reversed the order. Why is that?
Normally I would recommend using the compiler.cpp.extra_flags property to inject the additional flag into the compilation command instead of compiler.cpp.flags, as compiler.cpp.extra_flags was added to the platform for exactly this sort of use case. But unfortunately the developers of the "esp32" boards platform made the poor decision to place the {compiler.cpp.extra_flags} reference before the reference to compiler.cpp.flags in the compilation command template, which makes it impossible to use compiler.cpp.extra_flags to override flags from compiler.cpp.flags (since when a flag is used multiple times, the later occurrence overrides the prior one). So compiler.cpp.extra_flags can't be used.
Would you please change the order for the compiler flags? Please.
Sketch
N/A
Debug Message
warning: use of 'auto' in parameter declaration only available with '-std=c++20' or '-fconcepts'
warning: range-based 'for' loops with initializer only available with '-std=c++20' or '-std=gnu++20' [-Wc++20-extensions]
Other Steps to Reproduce
N/A
I have checked existing issues, online documentation and the Troubleshooting Guide
- I confirm I have checked existing issues, online documentation and Troubleshooting guide.
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 5 comments 2 replies
-
My current workaround in the platform.local.txt is as follows.
compiler.cpp.flags=-MMD -c "@{compiler.sdk.path}/flags/cpp_flags" -std=gnu++20 -Wno-volatile {compiler.warning_flags} {compiler.optimization_flags} {compiler.common_werror_flags}
However, this is not the normal way and should not be done.
Beta Was this translation helpful? Give feedback.
All reactions
-
Since you have a use case, why not open a PR with the changes you need? We are open source and accept pull requests from the community
Beta Was this translation helpful? Give feedback.
All reactions
-
I haven't dealt with the problem for a long time. I want to do a complete PR and test it myself beforehand. I have a question about this. In which file(s) do I have to make changes to change the order of execution?
(Ich habe mich lange Zeit nicht mit dem Problem beschäftigt. Ich möchte einen kompletten PR machen und vorher selbst testen. Ich hätte dazu eine Frage. In welcher Datei/welchen Dateien muss ich Änderungen machen um die Reihenfolge der Verarbeitung zu ändern?)
Beta Was this translation helpful? Give feedback.
All reactions
-
In which file(s) do I have to make changes to change the order of execution?
In platform.txt:
Lines 147 to 154 in 571c2f7
Note that the {compiler.c.extra_flags}, {compiler.cpp.extra_flags}, and {compiler.S.extra_flags} references are placed first in the command patterns. This placement makes it impossible for advanced users to use these properties to override the flags that are added to the commands by the platform by default.
Your own real world use case has been rendered outdated since the time you submitted this request by espressif/esp32-arduino-lib-builder#291, so I'll provide a slightly adjusted example that is still relevant. Let's say you wanted to use C++23 constructs in your projects. The platform adds the -std=gnu++2a flag (which causes the C++20 standard to be used) to the C++ compilation command, so in order to use C++23, you need to add the -std=gnu++23 flag to the C++ compilation command.
The good news is the platform follows the standard convention of providing a set of "extra_flags" properties to allow advanced users to inject arbitrary arguments into the compilation commands. The property for adding arguments to the C++ compilation command is named compiler.cpp.extra_flags. So we would expect to be able to cause the compilation commands to use the C++23 standard by setting the compiler.cpp.extra_flags property to -std=gnu++23. We could do this by using the --build-property flag when compiling the sketch using Arduino CLI:
$ arduino-cli compile --build-property "compiler.cpp.extra_flags=-std=gnu++23" --fqbn esp32:esp32:esp32
or by adding a platform.local.txt file to our platform installation
compiler.cpp.extra_flags=-std=gnu++23
However, with the current configuration of the platform, this would have no effect. The reason is that the compiler.cpp.extra_flags property is referenced in recipe.cpp.o.pattern before the reference to the compiler.cpp.flags and the -std=gnu++2a flag comes from compiler.cpp.flags (via "@{compiler.sdk.path}/flags/cpp_flags"), so you end up with a compilation command equivalent to this:
xtensa-esp32-elf-g++ -std=gnu++23 -std=gnu++2a
In cases where two flags conflict, the flag that comes later overrides the prior occurrences of the flag, so the above is equivalent to:
xtensa-esp32-elf-g++ -std=gnu++2a
If the "extra_flags" property references were placed later in the compilation command patterns, this would allow the advanced user the freedom to override the platform's default flags via the "extra_flags" properties. This is how it is done in Arduino's platforms (example).
Beta Was this translation helpful? Give feedback.
All reactions
-
Hi,
I'm so stupid. platform.txt. That's what gave me the idea in the first place. That's embarrassing.
Even though the ESP toolchain has now been updated to C++20 as the default setting, the problem with the flag sequence remains. Just as you write and just as we found out at the beginning. I'll test that. Thank you very much.
Beta Was this translation helpful? Give feedback.
All reactions
-
Hi,
Unfortunately, a few changes in the sequence are not enough. The problem is that all flags are in the file cpp_flags.
C:\Users\...\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.4-2f7dcd86-v1\esp32s3\flags\
I still have no idea how to change this with simple methods. I fear that major changes are necessary here, the scope of which I do not yet have an overview of.
A small side note. In the cpp_flags file there are two options for the standard. -std=gnu++2b and -std=gnu++2a. :-)
Beta Was this translation helpful? Give feedback.
All reactions
-
The problem is that all flags are in the file cpp_flags.
That is no problem. Please take the time to carefully read what I wrote in my previous reply. I went to a lot of effort to explain the situation thoroughly. Note this part:
with the current configuration of the platform, this would have no effect. The reason is that the
compiler.cpp.extra_flagsproperty is referenced inrecipe.cpp.o.patternbefore the reference to thecompiler.cpp.flagsand the-std=gnu++2aflag comes fromcompiler.cpp.flags(via"@{compiler.sdk.path}/flags/cpp_flags"), so you end up with a compilation command equivalent to this:xtensa-esp32-elf-g++ -std=gnu++23 -std=gnu++2aIn cases where two flags conflict, the flag that comes later overrides the prior occurrences of the flag, so the above is equivalent to:
xtensa-esp32-elf-g++ -std=gnu++2aIf the "extra_flags" property references were placed later in the compilation command patterns, this would allow the advanced user the freedom to override the platform's default flags via the "extra_flags" properties.
I still have no idea how to change this with simple methods.
You would have an idea if you had read my previous reply carefully. Please do that and then perform some simple experiments. I think everything will be clear to you then.
In the cpp_flags file there are two options for the standard. -std=gnu++2b and -std=gnu++2a. :-)
It is maybe a bit confusing, but as I said in my previous reply:
In cases where two flags conflict, the flag that comes later overrides the prior occurrences of the flag
So this command:
xtensa-esp32-elf-g++ -std=gnu++2b -std=gnu++2ais equivalent to this one:
xtensa-esp32-elf-g++ -std=gnu++2a
Beta Was this translation helpful? Give feedback.