I would like to see an example project that actually uses
build.mk to include third-party source from a library that includes both
I would also like to see a more detailed explanation of the
Why is there an
APPSOURCES as well as a
CSRC make variables? What do these do, and why must the source file list be duplicated?
USRSRC_SLASH? What is
Where is the
target_files make function defined? It does not seem to be part of standard make. What does it actually do?
I'll second this. I just played around a little bit, and can confirm that the presence of
build.mk in the app directory does cause it to be used. However, it seems to be a very sharp-edged feature, and I imagine if it isn't very well defined it could easily and silently break building.
In my case I used the following, inspired from
TARGET_MAIN_SRC_PATH = ./
CPPSRC += $(call target_files,$(TARGET_MAIN_SRC_PATH),*.cpp)
CSRC += $(call target_files,$(TARGET_MAIN_SRC_PATH),*.c)
(Please note that it's a verbatim copy except that I had to update
While compiling, I could see that it was pulling in the CPP files, and the resulting binary file is identical. So success, maybe?
I have a concern about a customized
build.mk file staying compatible with future Particle CLI upgrades. In my case, all I want to do is augment the compiler flags to use more warnings (Problems turning on -Werror), and nothing else. I worry that I will silently break things if I am, in addition to adding CFLAGS, accidentally overwriting critical Makefile variables.
I figured out how to do it by reading through the makefiles, but given that none it is documented, I share your concerns about future breakage.
In my case I’m also trying to share libraries between related firmware projects, and wanting to keep everything versioned in one repo (using submodules or subtrees so everything is reproducible).
The makefile that includes build.mk is ultimately in the particle firmware source tree. If you’re looking to understand things on your own, look for where it the firmware Makefiles include
build.mk, and work backwards. There are some critical variables, but some are explicitly extension points for
build.mk to modify.
@rickkas7 gives a minimum version at Problems turning on -Werror. Thanks!
I would like to know what sort of soft-guarantees could be made about future breakage. For instance, if I introduce variables into that Makefile, is there a prefix we can use which particle promises to reserve for forever? I know I can do something complex like
KENZ_KRAZY_KEYWORD_PWD ?= /home/kenz, but if Particle promises to reserve something specific (
USR_?) then it can unit test against any accidental use of that.
I found Build - Particle Firmware. I'm not sure who maintains it or what it's source is from. It looks like it might be a little bit dated, but it's been very helpful to understanding the Particle build system.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.