Application build with vendor target toolchain fails with rtems make build support

[Martin Erik Werner]

When building an application using the make build support (as given by the example in make/Templates/Makefile.leaf), and when the used toolchain has a vendor identifier as part of the target triplet (for example sparc-gaisler-rtems5), the build fails with the following kind of error:

<user_path>/make/custom/default.cfg:14: <user_path>/sparc-rtems5/leon3/make/bsp.cfg: No such file or directory                       
make: *** No rule to make target '<user_path>/sparc-rtems5/leon3/make/bsp.cfg'.  Stop.                                                                                  

This seems to be due to make/custom/default.cfg which uses:

!#make
(...)
RTEMS_TARGET = $(RTEMS_CPU)-rtems$(RTEMS_API)

include $(RTEMS_ROOT)/$(RTEMS_TARGET)/$(RTEMS_BSP)/make/target.cfg
include $(RTEMS_SHARE)/make/host.cfg

include $(RTEMS_ROOT)/make/main.cfg
include $(RTEMS_ROOT)/$(RTEMS_TARGET)/$(RTEMS_BSP)/make/bsp.cfg

where RTEMS_CPU does not include the vendor id, and hence gives an incorrect target triplet in RTEMS_TARGET.

This seems to be a regression between rtems 4.11 and rtems 5 introduced in

​270c5df5/rtems

[Chris Johns]

Does your build system provide RTEMS_TARGET?

How do you specify the sparc-gaisier label?

[Martin Erik Werner]

My build system does not touch RTEMS_TARGET, I'm using a Makefile based on the Makefile.leaf template:

!#make
# C source names, if any, go here -- minus the .c
C_PIECES=foo
C_FILES=$(C_PIECES:%=%.c)
C_O_FILES=$(C_PIECES:%=${ARCH}/%.o)

SRCS=$(C_FILES) $(CC_FILES) $(H_FILES) $(S_FILES)
OBJS=$(C_O_FILES) $(CC_O_FILES) $(S_O_FILES)

PGMS=${ARCH}/foo.exe

include $(RTEMS_MAKEFILE_PATH)/Makefile.inc
include $(RTEMS_CUSTOM)
include $(RTEMS_ROOT)/make/leaf.cfg

all:	${ARCH} $(SRCS) $(PGMS)

# The following links using C rules.
${ARCH}/foo.exe: ${OBJS} ${LINK_FILES}
	$(make-exe)

and pointing RTEMS_MAKEFILE_PATH to a compiled and installed version of an RTEMS BSP.

The sparc-gaisler-rtems5 triplet is given by the toolchain, in my case this is taken directly from rcc-1.3.1-gcc from ​https://www.gaisler.com/index.php/products/operating-systems/rtems .

However I would guess that this problem would apply to any toolchain with a vendor in its name (even "unknown").