Ladies and gentlemen, geeks of all kinds… I haven’t been here for a while, because we were busy getting our bouncing baby ModusToolbox v2.2 out the door. “We” is a huge team (see page iii for the v2.1 team). This tool is faster, leaner, and more flexible. (My editor would not let me say "flexibler." Go figure.) In some ways it is 4x faster and 100x leaner.
I don’t expect you to take my word for it. Here’s how that happened. ModusToolbox v2.2 introduces a new way to handle libraries. I love libraries – both the book kind and the software kind. One takes me of to an entirely new universe. The other does my work for me – I get to use someone else’s code. These are good things.
For those who love great books, this is all explained in the Library Manager User Guide. OK, maybe not a great book, the plot is a bit thin, but it is really useful. CJ (who is the tip of that particular spear) explains all this. When you start working for real with v2.2, go read it. That’s where I went when I was figuring out why the tool got a whole lot faster.
Version 2.1: the make system reads a URL (in a .lib file) and fetches that library, which may include more .lib files. The process proceeds recursively until all libraries are found and added to the application’s folder. Each time you create an application you may get yet another copy of the same library. This duplication takes time (slower), every application has every library (fatter), and that’s how it works (no choice).
Version 2.2 introduces shared libraries. For this it uses a .mtb file rather than a .lib file. So we call it the MTB flow rather than the older LIB flow. The mtb file adds a neat twist we’ll talk about in a moment. CJ tells you all the details in the documentation. But let’s talk.
You know your application needs a particular library, say a BSP. The deps folder in the application has the .mtb file for that library. If the BSP requires other libraries, those are represented by .mtb files in that library’s deps folder, and they are processed recursively. So far, this is how .lib files worked. So what’s different?
Here’s what changed.
The .mtb file has both the URL for the library I want, and a pointer to a shared location where the library might already exist. The default location is the mtb_shared folder. If the same version of the same library is already in the shared location, WOOHOO the make system doesn’t need to download it again. So you end up with faster (less to download) and leaner (a single small file that points to the library, instead of maybe 100 megs and 4,000 source files in your application folder). If the library isn’t there or it’s a different version, then the make system fetches it, just like before.
The make system also creates an mtb.mk file that keeps track of which library is used in the application, and where it is. You don’t need to deal with any of this, because it all just works. However, knowing a bit about the secret sauce is always a good thing.
OK, that’s faster and leaner. What about flexible? By default we share libraries. But you decide what’s shared and what’s specific to an individual application. If you want to treat it as app-specific, then your app gets the entire library, and you can do with it as you please without affecting any other application in your universe. You can still lock on any released version of any library. Talk about flexible!
So, why do this? Well, for one we eat our own dogfood around here. The process took too long. More importantly we listen to customers. You didn’t like it either.
You may want to get ModusToolbox v2.2 sooner rather than later. Keep in mind you still need to get the library the first time, so that it is in the shared folder. Some older code examples won’t use the .mtb mechanism until we update them, so you may not see the improvement all the time. But when you do…
I did a little informal measurement on my machine, with my home wireless network access. Your mileage will vary of course. In the end, with shared libraries already in place from other apps, ModusToolbox v2.2 created Hello World four times faster, and the application occupied 1/100th of the disk space. I’ll take a 4X speed and 100X space optimization any day.
Finally, depending on how you work, your company’s rules, and all that good stuff, you may not use our make system at all. A common real-world workflow is to learn how this is all put together, what the dependencies are (handled automagically in our make system) and then fetch the libraries and versions you want from GitHub. Install them on your company’s server(s) and you have the “blessed” known good code in your own system. Point your development project at that code using whatever environment you want, and go! It is a testament to the elegance of the ModusToolbox design that you can completely disregard the fundamental underpinning of the entire structure, and it still works.
If you are new to ModusToolbox, or you want to dive into some aspect of the tool that you aren’t familiar with, check out our ModusToolbox 101 training material on GitHub. This material will update for version 2.2 within a day or two of release. The table of contents for this course is awesome. So is the content.
Cheers, and happy coding!