[PATCH] build: Use build context for custom commands

[Chris Johns]

On 12/9/2023 5:55 pm, Sebastian Huber wrote:
> On 12.09.23 09:43, Chris Johns wrote:
>>>>> Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the
>>>>> configuration
>>>>> file always worked.
>>>> Great. I am seeing:
>>>>
>>>> OPTIMIZATION_FLAGS = -O2 -g -fdata-sections -ffunction-sections
>>>>
>>>> and data sections is an optimisation however does it complicates things for the
>>>> user if they play with with just -O2?
>>>>
>>>> 1. -g is debug info and not optimisation
>>>>
>>>> 2. we recommend building RTEMS with -fdata-sections -ffunction-sections so I
>>>> guess removing them would not be good
>>> We can easily split up the OPTIMIZATION_FLAGS and add more options. For example:
>>>
>>> DEBUG_FLAGS = -g
>>>
>>> OPTIMIZATION_FLAGS = -O2 -fdata-sections -ffunction-sections
>>>
>> I think it will help.
>>
>> As an idea what about DEBUGGING_OPTIONS and OPTIMIZATION_OPTIONS then
>> OPTIMIZATION_FLAGS is "${OPTIMIZATION_OPTIONS} ${DEBUGGING_OPTIONS}" so it
>> follows the gcc naming of its option grouping [1] ?
>>
>> Chris
>>
>> [1]https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
> 
> Yes, using OPTIONS instead of FLAGS is more in line with the GCC documentation,
> however, we currently use FLAGS for this stuff:
> 
> grep -r -o -h '\w*FLAGS' spec | sort -u
> ABI_FLAGS
> ARFLAGS
> ASFLAGS
> BSP_CFLAGS
> BSP_OPTIMIZATION_FLAGS
> CC_WARNING_FLAGS
> CFLAGS
> COVERAGE_COMPILER_FLAGS
> COVERAGE_LINKER_FLAGS
> CPPFLAGS
> CPUKIT_OPTIMIZATION_FLAGS
> CPU_CFLAGS
> CXXFLAGS
> CXX_WARNING_FLAGS
> LDFLAGS
> LINKFLAGS
> MPC55XX_BOOTFLAGS
> OPTIMIZATION_FLAGS
> PKGCONFIG_LDFLAGS
> TEST_DL01_CPPFLAGS
> TEST_DL02_CPPFLAGS
> TEST_DL04_CPPFLAGS
> TEST_DL05_CPPFLAGS
> TEST_DL06_CPPFLAGS
> TEST_DL07_CPPFLAGS
> TEST_DL08_CPPFLAGS
> TEST_DL09_CPPFLAGS
> TEST_DL10_CPPFLAGS
> TEST_DL11_CPPFLAGS
> TEST_OPTIMIZATION_FLAGS
> TEST_TAR01_CPPFLAGS
> TEST_TAR02_CPPFLAGS
> TEST_psxftw01_CPPFLAGS
> TMS570_LINKFLAGS
> WARNING_FLAGS
> XCFLAGS
> 
> I guess it is derived from CFLAGS, etc.

Yes. The thinking is OPTIONS is user focused and can be a set of options from
that section of the gcc manual while FLAGS are build system focused? We need
FLAGS like OPTIMIZATION_FLAGS and we make the distinction that user can change
OPTIONS and if you touch FLAGS you need to be more careful. We keep the ABI
machine flags away from OPTIONS and in FLAGS.

Chris