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. It is powerful and flexible, and for most users transparent. It just works. For example, you don’t need to specify individual source files in the makefile. The process auto-discovers source files in the project directory. 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.

https://github.com/cypresssemiconductorco/TARGET_CY8CPROTO-062-4343W/#latest-v1.X

 

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.

1280px-Libum_Sweet_Cheesecake_ingredients_&_recipe_(8411812870).jpg

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!” 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. 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.

ThisWay.jpg

Kyoto garden path; image credit: me