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
