Re: [PATCH] build: Use build context for custom commands
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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
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.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
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.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
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.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
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.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
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
Re: [PATCH] build: Use build context for custom commands
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? 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 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
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. > 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 Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
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. Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the configuration file always worked. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
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? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
