On Jun 19, 2020, at 3:05 AM, Ben Franksen via Core-talk <
core-talk at aps.anl.gov> wrote:
I just noticed that settings made in
configure/os/CONFIG_SITE.Common.linuxCommon
such as these
OPT_CFLAGS_YES += -g
OPT_CXXFLAGS_YES += -g
don't seem to have any effect. More precisely, while the file gets
included, the settings in there are overwritten by a later include of
configure/CONFIG.gnuCommon
which has
OPT_CFLAGS_YES = -O3
OPT_CXXFLAGS_YES = -O3
This can be seen in base-7.0 with 'make show-makefiles' (assuming it
shows the included makefiles in the order in which they are included). I
also used 'make -p|grep -B1 OPT_CFLAGS_YES’.
‘make show-makefiles’ does list the files in the order in which they are included. You generally need to be inside an O.<arch> directory to see the full list of files used at build-time though.
I did not manage to find out what causes the unexpected include order here.
This is the relevant part of configure/CONFIG, with some unrelated lines removed:
# Host architecture specific definitions
#
include
$(CONFIG)/os/CONFIG.$(EPICS_HOST_ARCH).Common
-include
$(CONFIG)/os/CONFIG_SITE.$(EPICS_HOST_ARCH).Common
ifdef
T_A
# Cross compile specific definitions
#
ifneq ($(EPICS_HOST_ARCH),$(T_A))
include
$(CONFIG)/CONFIG.CrossCommon
endif
# Target architecture specific definitions
#
-include
$(CONFIG)/os/CONFIG.Common.$(T_A)
# Host-Target architecture specific definitions
#
-include
$(CONFIG)/os/CONFIG.$(EPICS_HOST_ARCH).$(T_A)
# Site specific target and host-target definitions and overrides
#
-include
$(CONFIG)/os/CONFIG_SITE.Common.$(T_A)
-include
$(CONFIG)/os/CONFIG_SITE.$(EPICS_HOST_ARCH).$(T_A)
endif
# ifdef T_A
Where does the CONFIG_SITE.Common.linuxCommon file appear in the above include order? It comes from CONFIG.Common.linuxCommon, and that gets included from CONFIG.Common.linux-x86_64 so it’s from the CONFIG.Common.$(T_A) line.
The CONFIG.gnuCommon file was designed to be pulled in early, which you can tell because it sets lots of variables using = instead of +=. The configure/CONFIG.CrossCommon file actually includes it, so that happens before any TA-specific line above (but
only when doing is a cross-build, which this case isn’t so the CONFIG.CrossCommon file is irrelevant here).
There are actually quite a few CONFIG files under configure/ which include the CONFIG.gnuCommon file, here’s the full list:
woz$
git grep /CONFIG.gnuCommon
CONFIG.CrossCommon:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.Common.iosCommon:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.cygwin-x86.cygwin-x86:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.darwinCommon.darwinCommon:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.freebsd-x86.freebsd-x86:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.freebsd-x86_64.freebsd-x86_64:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.linux-arm.linux-arm:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.linux-ppc.linux-ppc:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.linux-x86.linux-x86:#include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.linux-x86.win32-x86-mingw:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.solaris-sparc-gnu.solaris-sparc-gnu:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.solaris-x86-gnu.solaris-x86-gnu:include
$(CONFIG)/CONFIG.gnuCommon
os/CONFIG.win32-x86-mingw.win32-x86-mingw:include
$(CONFIG)/CONFIG.gnuCommon
Most of those are CONFIG.$(EPICS_HOST_ARCH).$(T_A) files, so they will be included after the CONFIG.Common.$(T_A) file and thus settings in the CONFIG.gnuCommon file will override any from the CONFIG_SITE.Common.linuxCommon file.
The reasons for the above are (of course) historical. Back in the days before VxWorks 5 Wind River used the native SunOS Sun-3 C compiler to build code for m68k targets, since the Sun-3 machines were also based on m68k. When Sun’s Sparc CPUs arrived and
they also wanted to add other CPU families they they had to find an alternative compiler, and they adopted GCC (I just found the sources for gcc-1.37.1 in our old VxWorks 5.0.1 tree). Thus the EPICS build system started out using GCC for cross-builds only.
I could reorganize the include order, but (to Michael’s immense frustration I’m sure) I am reluctant to break the out-of-tree target architectures that I know many sites use, and switching things around would be highly likely to do that.