[PATCH] build: Use build context for custom commands

Chris Johns chrisj at rtems.org
Tue Sep 12 07:43:41 UTC 2023


On 12/9/2023 5:32 pm, Sebastian Huber wrote:
> On 12.09.23 08:49, Chris Johns wrote:
>> On 12/9/2023 2:15 pm, Sebastian Huber wrote:
>>> On 12.09.23 03:26, Chris Johns wrote:
>>>> On 11/9/2023 7:37 pm, Sebastian Huber wrote:
>>>>> Revert duplicated listing of TEST_OPTIMIZATION_FLAGS.
>>>> Thank you for picking this up.
>>>>
>>>> Does this change let the user control TEST_OPTIMIZATION_FLAGS and
>>>> OPTIMIZATION_FLAGS via a BSP setting in config.ini?
>>> No, this patch fixes the bld.asm(), bld.cc(), and bld.cxx() functions to use the
>>> build item context for the flags.
>> Sure and thanks.
> 
> Ok, good. Is the patch all right to commit?

Yes.

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


More information about the devel mailing list