That’s the idea, anyway. Greetings, fellow geeks.
The previous blog was a bit philosophical about monolithic vs. modular. Bottom line, with ModusToolbox we took a traditional SDK and turned it into a flexible collection of smaller pieces. In that context, let’s talk about libraries.
ModusToolbox implements a project creation system built on GNU make. See It's Make Time. If you become master of the make system, you can do remarkable things. I think I’ll add that to my list. But for now, libraries.
To implement flexibility, the project creation system locates and parses .lib files. What is that? Here’s an example. This is the entirety of a .lib file. It is a one-line URL to a git repository (we use GitHub) and a specific commit within that repo.
You use the Project Creator to pick a BSP and an example application. There are hundreds of examples. The project creation system reads the .lib file(s) in the application folder. It goes to GitHub, downloads the code, checks out the specified version, and a local copy of that code appears in your project folder. It then recursively searches that new library for more .lib files. In this way any library can ensure that other libraries it depends upon are included. In the end, all the source files appear in your project folder. Done.
I need this library. Aha, but that needs these other libraries. No problem, let’s get those ingredients. All the ingredients are identified and fetched.
I might have to make this. Roman-era sweet cheesecake ingredients; image credit: Carole Raddato, Wikimedia Commons
Like any good cookbook, the potential for creativity is immense. In this case each ingredient is a library. Over time, most have multiple releases. There are some amazingly great things that flow to you from this design.
You can use the Library Manager to add, remove, or update libraries. It’s trivially easy.
If you want a specific version of a library, it’s easy to do that in the .lib file or the Library Manager. You can lock on a “known good” version rather than the latest and greatest, whatever works for you.
Because each library is released separately, they update asynchronously. That’s good, you get improvements faster. It can be bad if incompatibilities appear: version Y of a library no longer works with version X of some other library. That does happen. The flexibility of the build system gives you an easy fix. Lock down on versions that you know work together.
You can add your own .lib files. Obviously writing a .lib file is trivial. It does not need to point to our GitHub presence. The system is based on git, so the file can point to any git repository. If you have a preferred library for some task or problem domain, use it and don’t use ours. Unless there is a dependency among our libraries, this is no muss, no fuss, no worries.
Bottom line, this approach is limitless. Each library, or dependent collection of libraries, is self-contained and self-defining. If you add the WiFi Connection Manager library, all the required libraries just appear in your project. You don’t need to know subtle dependencies, which is brilliant.
I think our build infrastructure is a fabulous tool and it just works. That’s not trivial! But there are side effects.
For one thing, it replicates each library in each project every time. A project can have thousands of files, and many of them are the same from project to project. I suspect most developers won’t like that. “I’ve got four projects going, I don’t need four local copies of your driver library!” EDIT: after I wrote this blog, we fixed this. You can share a library among multiple projects if you want. See Faster Leaner More Flexible – ModusToolbox v2.2 and Lock and Load
Your company may have its own server full of approved libraries and code with which you create your magic. Not a problem.
We like the ModusToolbox make infrastructure. We think you’ll like it. We designed it to be immensely flexible. See It's Make Time.
If it doesn’t work for you, don’t use it! You don’t need to use our build infrastructure if it doesn’t work for you. The build infrastructure and examples show you what you need. Once you understand that, go to GitHub, get what you want, and use it as you see fit. One library or a dozen; whatever version, low-level drivers or a high-end solution. The choice is yours. A design that enables that is a very cool design.
Take the path that works for you.
Kyoto garden path; image credit: me
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.