[PATCH] build: Use build context for custom commands

[Chris Johns]

On 13/9/2023 6:52 pm, Sebastian Huber wrote:
> On 13.09.23 09:20, Chris Johns wrote:
>> 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.
> 
> I am not against a big overhaul of the build options, but then we should
> document the patterns and review all options.

Great and yes. When?

Chris