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 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 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: Add target to build scripts
On 11.08.23 07:51, Sebastian Huber wrote: On 11.08.23 07:40, Chris Johns wrote: On 11/8/2023 3:33 pm, Sebastian Huber wrote: On 11.08.23 02:21, Chris Johns wrote: On 10/8/2023 7:02 pm, Sebastian Huber wrote: Document that the build scripts in the testsuites produce a test program. I am sorry but I do not understand this change and why we need it. Is the addition of the target line purely cosmetic? This information can be used to associate test executables with build items and vice versa. We just these tests? These are the only tests which are produced by a build script. The other tests already have a target attribute. I am struggling to see a need. If you have a need it may help to outline it. This can be used to improve the quality of test documents which use the build specification and a test report in JSON as input. Also I cannot see anything we have to make sure the path is valid. Yes, currently the path in the target attribute and in the script have a bit of redundancy. I don't think it is worth the cost to get rid of this redundancy since we have it only in a couple of files. Any objections to commit this patch? -- 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
[PATCH 1/2] score: Fix RTEMS_DEFINE_GLOBAL_SYMBOL()
The availability of a proper RTEMS_DEFINE_GLOBAL_SYMBOL() implementation
depends on __asm__() and thus __GNUC__.
Clarify documentation.
Update #4953.
---
cpukit/include/rtems/score/basedefs.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/cpukit/include/rtems/score/basedefs.h
b/cpukit/include/rtems/score/basedefs.h
index 99fda67e8c..0cf7272b5d 100644
--- a/cpukit/include/rtems/score/basedefs.h
+++ b/cpukit/include/rtems/score/basedefs.h
@@ -999,11 +999,12 @@ extern "C" {
*
* @param _value is the value of the symbol. On the value a macro expansion is
* performed and afterwards it is stringified. It shall expand to an integer
- * expression understood by the assembler.
+ * expression understood by the assembler. The value shall be representable
+ * in the code model of the target architecture.
*
* This macro shall be placed at file scope.
*/
-#if defined(__USER_LABEL_PREFIX__)
+#if defined(__GNUC__)
#define RTEMS_DEFINE_GLOBAL_SYMBOL( _name, _value ) \
__asm__( \
"\t.globl " RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) \
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] tests: Improve RTEMS_DEFINE_GLOBAL_SYMBOL() tests
Use a symbol value relative to an existing symbol address to make the
test work on more code models.
Update #4953.
---
testsuites/sptests/spmisc01/init.c | 11 +--
testsuites/validation/tc-basedefs.c | 18 +++---
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/testsuites/sptests/spmisc01/init.c
b/testsuites/sptests/spmisc01/init.c
index 62b2f69dbc..8c46245af9 100644
--- a/testsuites/sptests/spmisc01/init.c
+++ b/testsuites/sptests/spmisc01/init.c
@@ -122,9 +122,14 @@ static int obfuscate_variable(int i)
return i;
}
+static int global_symbol_base;
+
RTEMS_DECLARE_GLOBAL_SYMBOL(a_global_symbol);
-RTEMS_DEFINE_GLOBAL_SYMBOL(a_global_symbol, 0xabc);
+RTEMS_DEFINE_GLOBAL_SYMBOL(
+ a_global_symbol,
+ RTEMS_SYMBOL_NAME(global_symbol_base) + 0xabc
+);
RTEMS_STATIC_ASSERT(0 != 1, zero_neq_one);
@@ -243,7 +248,9 @@ static void Init(rtems_task_argument arg)
unreachable();
rtems_test_assert(printflike_func("%i", 0) == 56);
rtems_test_assert(obfuscate_variable(63) == 63);
- rtems_test_assert((uintptr_t)a_global_symbol == 0xabc);
+ rtems_test_assert(
+(uintptr_t) a_global_symbol - (uintptr_t) &global_symbol_base == 0xabc
+ );
rtems_test_assert(RTEMS_ARRAY_SIZE(array) == 3);
rtems_test_assert(sizeof(zero_length_array_struct) == 4);
container_of();
diff --git a/testsuites/validation/tc-basedefs.c
b/testsuites/validation/tc-basedefs.c
index 94600f5241..28c11af505 100644
--- a/testsuites/validation/tc-basedefs.c
+++ b/testsuites/validation/tc-basedefs.c
@@ -527,8 +527,12 @@ RTEMS_COMPILER_PURE_ATTRIBUTE static int
compiler_pure_attribute_func( void )
return 21;
}
+static int global_symbol_base;
+
RTEMS_DEFINE_GLOBAL_SYMBOL(
- GLOBAL_SYMBOL, GLOBAL_SYMBOL_VALULE( abc ) );
+ GLOBAL_SYMBOL,
+ RTEMS_SYMBOL_NAME( global_symbol_base ) + GLOBAL_SYMBOL_VALULE( abc )
+);
static int deprecated_func( int i ) RTEMS_DEPRECATED;
static int deprecated_func( int i )
@@ -1055,7 +1059,11 @@ static void RtemsBasedefsValBasedefs_Action_18( void )
* which is defined in a file different from the file in which the gobal
* symbol is defined.
*/
- T_step_eq_int( 45, basedefs_get_global_symbol(), 0xabc );
+ T_step_eq_uptr(
+45,
+basedefs_get_global_symbol() - (uintptr_t) &global_symbol_base,
+0xabc
+ );
}
/**
@@ -1089,7 +1097,11 @@ static void RtemsBasedefsValBasedefs_Action_20( void )
* Check that the RTEMS_DEFINE_GLOBAL_SYMBOL() macro defines a global symbol
* with the correct value.
*/
- T_step_eq_int( 49, (uintptr_t) global_symbol, 0xabc );
+ T_step_eq_uptr(
+49,
+(uintptr_t) global_symbol - (uintptr_t) &global_symbol_base,
+0xabc
+ );
}
/**
--
2.35.3
___
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 1/2] score: Fix RTEMS_DEFINE_GLOBAL_SYMBOL()
OK
Thanks
Chris
On 13/9/2023 12:44 am, Sebastian Huber wrote:
> The availability of a proper RTEMS_DEFINE_GLOBAL_SYMBOL() implementation
> depends on __asm__() and thus __GNUC__.
>
> Clarify documentation.
>
> Update #4953.
> ---
> cpukit/include/rtems/score/basedefs.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/basedefs.h
> b/cpukit/include/rtems/score/basedefs.h
> index 99fda67e8c..0cf7272b5d 100644
> --- a/cpukit/include/rtems/score/basedefs.h
> +++ b/cpukit/include/rtems/score/basedefs.h
> @@ -999,11 +999,12 @@ extern "C" {
> *
> * @param _value is the value of the symbol. On the value a macro expansion
> is
> * performed and afterwards it is stringified. It shall expand to an
> integer
> - * expression understood by the assembler.
> + * expression understood by the assembler. The value shall be
> representable
> + * in the code model of the target architecture.
> *
> * This macro shall be placed at file scope.
> */
> -#if defined(__USER_LABEL_PREFIX__)
> +#if defined(__GNUC__)
>#define RTEMS_DEFINE_GLOBAL_SYMBOL( _name, _value ) \
> __asm__( \
>"\t.globl " RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) \
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] build: Merge regulator build into library item
There is no need to use a separate build object item.
---
spec/build/cpukit/librtemscpu.yml | 5 +++--
spec/build/cpukit/objregulator.yml | 18 --
2 files changed, 3 insertions(+), 20 deletions(-)
delete mode 100644 spec/build/cpukit/objregulator.yml
diff --git a/spec/build/cpukit/librtemscpu.yml
b/spec/build/cpukit/librtemscpu.yml
index 7cf0863859..9061a8290c 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -152,6 +152,8 @@ install:
- cpukit/include/rtems/recorddata.h
- cpukit/include/rtems/recorddump.h
- cpukit/include/rtems/recordserver.h
+ - cpukit/include/rtems/regulator.h
+ - cpukit/include/rtems/regulatorimpl.h
- cpukit/include/rtems/ringbuf.h
- cpukit/include/rtems/rtc.h
- cpukit/include/rtems/rtems-debugger-remote-tcp.h
@@ -510,8 +512,6 @@ links:
uid: objmpci
- role: build-dependency
uid: objpci
-- role: build-dependency
- uid: objregulator
- role: build-dependency
uid: objpsxsgnl
- role: build-dependency
@@ -950,6 +950,7 @@ source:
- cpukit/libmisc/mouse/mouse_parser.c
- cpukit/libmisc/mouse/serial_mouse.c
- cpukit/libmisc/redirector/stdio-redirect.c
+- cpukit/libmisc/regulator/regulator.c
- cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c
- cpukit/libmisc/rtems-fdt/rtems-fdt.c
- cpukit/libmisc/stackchk/check.c
diff --git a/spec/build/cpukit/objregulator.yml
b/spec/build/cpukit/objregulator.yml
deleted file mode 100644
index 56d6154de9..00
--- a/spec/build/cpukit/objregulator.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
-build-type: objects
-cflags: []
-copyrights:
-- Copyright (C) 2023 OAR Corporatoin
-cppflags: []
-cxxflags: []
-enabled-by: true
-includes: []
-install:
-- destination: ${BSP_INCLUDEDIR}/rtems
- source:
- - cpukit/include/rtems/regulator.h
- - cpukit/include/rtems/regulatorimpl.h
-links: []
-source:
-- cpukit/libmisc/regulator/regulator.c
-type: build
--
2.35.3
___
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
