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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
