The ModusToolbox build system is built on GNU make. What I want to do in this blog is point out a couple of really neat things that result from that. I’m a GUI guy (for good or ill). Even I get how cool the make system is.
One of my all-time favorite things about GNU is that it is a recursive acronym. GNU stands for GNU’s Not Unix. So that first GNU stands for what? I love recursion.
Image credit: Aurelio A. Heckert, https://www.gnu.org/graphics/graphics.html
While I love a good UI, I also know that a command line is often much more capable. You can automate a build from the command line and make it do what you want; repeatedly and predictably. You often can’t do that at all with a UI.
The ModusToolbox build system is documented in the ModusToolbox User Guide. There is also a useful knowledgebase article on Managing the Makefile. Those two documents tell you the basics like how to add files, manage pre- and post-build operations, pick a BSP, specify a debug or release build, set compiler options, and so on. I’m not going to repeat the basics here. Let’s focus on how it works.
We added several targets to GNU make. The word target is overloaded in this case. It can be “the chip I’m working with” or “the file I want to work on.” In GNU world, a target can also be “an operation to accomplish.” For example, the clean operation is a make target. That’s the definition here, target = operation.
A good example of a target that we added is called getlibs. Use make getlibs and the build system recursively finds all libraries required for the project, then checks out the specified commit from a git repository. I talked about the end result in We Did It Your Way. The make getlibs command is how all that happens. There are a couple of nice GUI tools that sit on top of getlibs: Project Creator and Library Manager. When you create an application or add/remove/update a library, those tools use make getlibs to get it done.
There are other make targets available. For example, you can export a project into supported IDEs: Keil uVision, IAR Embedded Workbench, Visual Studio Code, or any Eclipse IDE. For example, type make ewarm TOOLCHAIN=IAR and you get an Embedded Workbench .ipcf file. Easy as that. See The March of IDEs. The make bsp target generates a custom BSP for your device. You identify the part by number, and you get a complete BSP specific to the part on your custom board. See Make Your Own BSP for Fun and Profit.
The key to all this is a fundamental simplicity to the design. Everything is controlled from the application’s makefile through a consistent set of variables. These variables enable you to get most of what you want done without getting in your way. For instance, if you don’t want the project creation process to auto-discover all your files, you can add them explicitly using the SOURCES and INCLUDES variables. You can add to or even replace your compiler and linker arguments from the makefile without needing to reverse-engineer the build system.
So the odds are good you don’t need to change the make system, although you can if you want to extend it or modify it. Mostly you just need to understand the variables we provided for you to use.
Under the hood, everything is performed through GNU make, which means command-line support is the base that the entire system is built on. For anyone who wants to integrate our builds into their automated workflow, a continuous integration system, or regression test suite, this is a very handy thing to have. See One Build to Make Them All. We use this feature extensively ourselves, part of our “eat your own dogfood” mentality. So if you like to have an IDE for project management but you prefer to manipulate the compiler from the command line, absolutely no worries. Issue a build command from either environment, the same thing happens under the hood.
ModusToolbox gives you an amazingly flexible build system that you can manipulate by setting values for variables, exports projects into an IDE easily, and that you can use as you see fit from either an IDE or a command line. You can use it transparently, or have fun making it your own.
By the way, in perfect alignment with how we deliver software, the entire make system is delivered to you, in source code, in the psoc6make repository on GitHub. A bit like the GNU recursive acronym, ModusToolbox make uses itself to get itself. I love recursion. So tell me, am I easily amused? Or is this as cool as I think it is.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
By technically required cookies we mean cookies without those the technical provision of the online service cannot be ensured. These include e.g. cookies supporting essential services like a smooth reproduction of video or audio footage. So called ‘functional cookies’ are also assigned belonging to this category. Functional cookies store information in order to provide you comfortable use of our online services (e.g. language selection). The legal basis for the processing of personal data by means of cookies of this category is Infineon’s legitimate interest. This includes, among other things, the interest in having a professional external presentation as well as an optimal balancing of the loads on the server due to technical reasons.
By performance and marketing cookies we mean cookies which are technically not required. We use performance and marketing cookies only if you have given us your prior consent. With such cookies, we collect information about how users interact with our website and which pages have been visited. This helps us to understand user activity on our website on an aggregated as well as on a personal level to provide you relevant content and services.