Requesting Complete Example using build.mk

Firmware Libraries
1

I would like to see an example project that actually uses build.mk to include third-party source from a library that includes both .cpp and .h files.

I would also like to see a more detailed explanation of the build.mk “boilerplate”.

Why is there an APPSOURCES as well as a CPPSRC and CSRC make variables? What do these do, and why must the source file list be duplicated?

What is USRSRC_SLASH? What is SOURCEPATH?

Where is the target_files make function defined? It does not seem to be part of standard make. What does it actually do?

1 Like
2

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 ~/.particle/toolchains/deviceOS/1.4.4/firmware-1.4.4/main/src/build.mk:

build.mk

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 TARGET_MAIN_SRC_PATH.)

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.

3

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.

4

@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.

5

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.

6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.