[PATCH] build: Use build context for custom commands

[Chris Johns]

On 13/9/2023 4:18 pm, Sebastian Huber wrote:
> 
> 
> On 13.09.23 03:12, Chris Johns wrote:
>> 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.
> 
> I think it is too late to introduce a new naming here. There may be already
> configuration files which use OPTIMIZATION_FLAGS. I would just split this option
> into OPTIMIZATION_FLAGS and DEBUGGING_FLAGS.

We have not released any of this however after that it is too late if we want or
need to change.