Feedback on build system xmake/xcommon etc

[Ross]

Hi,

xmos libraries and applications have typically used a build and dependency management system based on make and makefiles supplied in module_xcommon and provided with the xmos tools (xmos builds and ships an old version of make as xmake). There are some docs here: https://www.xmos.ai/documentation/XM-01 ... index.html

The dependency grabbing downloads from xmos.com directly. With a move to GitHub development these releases have not been maintained. Internal developers have also favoured cmake for a few reasons and designs have now got fragmented in terms of methodology. Some designs, such as USB Audio, have continued to use the old system while other projects, such as XCORE-VOICE use their own cmake based systems. The xcommon based system certainly does have its issues, dep grabbing only from xmos.com and maintainability being two high items high on my list.

Threads like the following show some disillusionment with the current arrangement and also some praise for the previously unified scheme: https://www.xmos.ai/documentation/XM-01 ... index.html.

My team has been tasked with again unifying the build and dep management systems and so I thought it would be prudent to ask for any input from users here. What did you like about the the old system? what don't you like? what feature would you like to see added/removed?

Thanks for your time.

[fabriceo]

Hi Ross, good to hear this initiative.

when we start a new project based on an xmos application (say audio usb) we basically recreate a local repository with all the components provided and we replicate this as our own GitHub project. then we modify and add tons of things.

so from my perspective the problem of version and dependencies with xmos.com or xmos.ai or GitHub/xmos doesn't exist.
if you guys update a library then we will eventually and very carefully integrate the module(s) into our source code by our own.
because we may have created incompatibilities or because we just don't want to publish something not fully tested or validated.

in other words, we ll use your solution (xmake or cmake) as it is and then we'll work from there with our own journey.

what is important to me is that xmos continues creating libraries/module that would be compatible with xmake projects (made with all the makefile.xcomon features). This framework has demonstrated enough flexibility and robustness.
The only thing which is missing in the module_build_info is a variable that could be called at different steps of the build, especially the end, for example I have created the followings:

Code: Select all

#FINISH_All = $(call XFLASH_FACTORY,$(1)) 
FINISH_All = $(call XFLASH_UPGRADE,2,$(1))
#FINISH_All = @echo Ready to Run with XTag3 with xscope

XFLASH_UPGRADE = @echo Creating upgrade $(1) image $(2).bin && xflash --verbose --no-compression --factory-version 14.3 --upgrade $(1) $(2).xe -o $(2).bin
XFLASH_FACTORY = pwd && xflash --verbose --no-compression --boot-partition-size 0xC0000 --factory $(1).xe 

which are called by an additional line added in Makefile.common1 around line 1220 in the .xe role:

Code: Select all

$(BIN_DIR)/$(APP_NAME).xe : $(XMOSUPDATE) $(HEADER_WARNINGS) $(REAL_OBJ_FILES) $(call UNMANGLE,$(XN_SOURCE_FILES))  $(call UNMANGLE, $(XTA_SOURCE_FILES)) $(call UNMANGLE,$(LIB_FILES)) $(call UNMANGLE, $(MODULE_XSCOPE_SOURCE_FILES)) $(call UNMANGLE, $(APP_XSCOPE_SOURCE_FILES)) $(PCA_FILE) $(CURRENT_MAKEFILE) $(TARGET_DIR)/_obj.rsp | $(BIN_DIR)/
	@echo Creating $(notdir $@)
	$(AT)cd $(TARGET_DIR) && $(XCC) $(TARGET_FLAGS) $(XCC_MAP_FLAGS) $(XCC_EXTRA_MAP_FLAGS) $(LIB_FLAGS) @_obj.rsp $(call TO_OS,$(foreach x,$(XN_SOURCE_FILES),$(CMDQUOTE)$(call DOTDOT,$(call UNMANGLE_NO_ESCAPE,$x))$(CMDQUOTE))) $(call TO_OS,$(foreach x,$(XTA_SOURCE_FILES),$(CMDQUOTE)$(call UNMANGLE_NO_ESCAPE,$(call DOTDOT,$x))$(CMDQUOTE))) $(XSCOPE_ARGS) -o $(CMDQUOTE)$(call TO_OS,$(call DOTDOT,$@))$(CMDQUOTE)
	$(call FINISH_All,$(BIN_DIR)/$(APP_NAME)) $(call FINISH_$(CONFIG),$(BIN_DIR)/$(APP_NAME))

[Ross]

Thanks very much for the feedback Fabriceo!