[PATCH] build: Use build context for custom commands

[Sebastian Huber]

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.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/