[PATCH] build: Use build context for custom commands

[Sebastian Huber]

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.

-- 
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/