Please correct the order in which the compiler flags are compiled?

[mikrocoder]

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.

[mikrocoder]

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.

[me-no-dev]

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

[mikrocoder]

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?)

[per1234]

In which file(s) do I have to make changes to change the order of execution?

In platform.txt:

arduino-esp32/platform.txt

Lines 147 to 154 in 571c2f7

	## Compile c files
	recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.c.extra_flags} {compiler.c.flags} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" -DARDUINO_VARIANT="{build.variant}" -DARDUINO_PARTITION_{build.partitions} {build.extra_flags} {compiler.cpreprocessor.flags} {includes} "@{build.opt.path}" "@{file_opts.path}" "{source_file}" -o "{object_file}"
	## Compile c++ files
	recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.extra_flags} {compiler.cpp.flags} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" -DARDUINO_VARIANT="{build.variant}" -DARDUINO_PARTITION_{build.partitions} {build.extra_flags} {compiler.cpreprocessor.flags} {includes} "@{build.opt.path}" "@{file_opts.path}" "{source_file}" -o "{object_file}"
	## Compile S files
	recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.S.extra_flags} {compiler.S.flags} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" -DARDUINO_VARIANT="{build.variant}" -DARDUINO_PARTITION_{build.partitions} {build.extra_flags} {compiler.cpreprocessor.flags} {includes} "@{build.opt.path}" "@{file_opts.path}" "{source_file}" -o "{object_file}"

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.patternbefore 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).

[mikrocoder]

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.

[mikrocoder]

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. :-)

[per1234]

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 wen 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_flags property is referenced in recipe.cpp.o.patternbefore 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.

---

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++2a

is equivalent to this one:

xtensa-esp32-elf-g++ -std=gnu++2a