Multiple build configurations improvements (IDFGH-10539)

[nebkat]

Is your feature request related to a problem?

I'd like to revisit the topic of multiple build configurations and continue the discussion from #5658.

Multiple build configurations are currently well supported using:

idf.py -B build-debug -DSDKCONFIG=build-production/sdkconfig
idf.py -B build-production -DSDKCONFIG=build-production/sdkconfig -DSDKCONFIG_DEFAULTS="sdkconfig.defaults;sdkconfig.prod"

Or even better with the following line:

set(SDKCONFIG "${CMAKE_BINARY_DIR}/sdkconfig")

However, the syntax remains quite awkward. Commands that would often be run quickly in succession e.g. idf.py build, idf.py app-flash, idf.py monitor all need the arguments to be provided, making it quite difficult to use without setting up custom scripts or environment variables.

This in turn is resulting in very low adoption of an otherwise excellent feature: just 11 instances of the above CMake snippet are found on GitHub. There are no doubt hundreds of developers making multiple clones of their repos in order to change a few menuconfig options (and then gitignoring sdkconfig because it is different between two targets).

Describe the solution you'd like.

Perhaps the simplest way this could be improved would be the adoption of a syntax similar to esptool, where a file path prefixed with @ would be appended to the list of arguments.

One could then define files such as:

// profiles/prod
-B build-production -DSDKCONFIG=build-production/sdkconfig -DSDKCONFIG_DEFAULTS="sdkconfig.defaults;sdkconfig.prod"

// profiles/debug
-B build-debug -DSDKCONFIG=build-debug/sdkconfig -DSDKCONFIG_DEFAULTS="sdkconfig.defaults;sdkconfig.debug"

And then call:

idf.py @profile/prod build
idf.py @profile/debug build

This would be an improvement even if the files simply contained e.g. -DAPP_PRODUCTION=1 and then CMake script did the rest as the interface with idf.py would be much improved.

CMake already supports a similar feature, though it is only for cache entries. -C is used in idf.py as the project path, so perhaps --initial-cache could be used instead.

Describe alternatives you've considered.

This can easily be achieved with custom scripts, but feels like something that should be available out-of-the-box.

Additional context.

Can submit a PR if idea sounds good.