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