Direkt zum Hauptbereich

Create your own

This post is special, in the sense that it marks an important event in my life as a software developer.
But let's start from the beginning...

oelint-adv

When you use bitbake/YOCTO on a frequent basis, you might have are checked out my linting tool for these file called oelint-adv.
This tool parses bitbake file and checks for several rules and best practices when it comes to working within this ecosystem.
Initially I thought about using the original bitbake parser, which is available as open source licensed under GPL-2.0 - Unfortunately it requires more or less a whole workspace setup, including all layers a.s.o.

As this was meant as a quick check tool to be used in CI or git pre-commit hooks, I was pretty sure that this wouldn't work, so I wrote my own parser for bitbake files, till then exclusively used with the linting tool.

Scancode-toolkit

All of a sudden, I got a few weeks back a ticket on my GitHub repo that somebody else had more or less the same issue - they wanted to parse single bitbake files, extract some information and use it for their very own purposes.
This tool is called scancode-toolkit, a wonderful tool to scan source code for licensing information.
And yeah I have to admit, I myself had a ticket to implement it into the meta-sca layer and rejected the idea after seeing the large amount of python dependencies it would inherit.
Funny side of the story my parser will be soon part of these dependencies, because nexB asked if my parser from the linter can be moved to an extra library, ready to use for you own bitbake automation.

Enter: oelint-parser

For me that was also a welcome opportunity to do some refactoring to the parser sources.
The result of that can now the found on GitHub and PyPi.

On a side note 

As this is more or less my first public python API, it was time to think about something like API documentation.
Luckily I stumbled upon the wonderful tool pydoc-markdown, which generates wonderful markdown documents out of python docstrings.
As I already commented almost all of my code with them it was easy to generate a API documentation in markdown, which you can view directly in your browser over at GitHub.

In case you want to reuse this for your own documentation, be sure to check the following files

But, hey, what's in it for me...?

With the parser being now available as a lib on its own, you can create your own automation for bitbake files, by wrapping the parser code with your own automation, just check this quick introduction.
Be sure to give it a try, I'm sure the possibilities are endless.
Feel free to contact my any time, if you face problems or want to discuss ideas - I would love to hear them.

And now...

Please all start using

Kommentare

Beliebte Posts aus diesem Blog

Speedup python on embedded systems

Have you ever considered to use python as a scripting language in an embedded system? I've been using this on recent projects although it wasn't my first choice. If I had to choose a scripting language to be used in embedded I always had a strong preference for shell/bash or lua, because they are either builtin or designed to have a significant lower footprint compared to others. Nevertheless the choice was python3 (was out of my hands to decide). When putting together the first builds using YOCTO I realized that there are two sides to python. the starting phase, where the app is initializing the execution phase, where the app just processes new data In the 2nd phase python3 has good tradeoffs between maintainability of code vs. execution speed, so there is nothing to moan about. Startup is the worst But the 1st phase where the python3-interpreter is starting is really bad. So I did some research where is might be coming from. Just to give a comparison of ...

Using bbclass based on conditions

When you are working with YOCTO build system, you might be aware of the construct .bbclass. For those who are not: these are code snippets which will be injected into the recipe itself. Mostly they add new tasks or provide some generalization for things you often. A good example might be pypi.bbclass. In your recipe you write usually something likes this SRC_URI = "https://www.foo.org/foo.tar.gz" When it comes to python packages a way more elegant way is to use pypi.org . And here does the pypi.bbclass provide some magic - you recipe will just look like this inherit pypi   PYPI_PACKAGE = "foo" the bbclass pypi will automatically translate the variable name PYPI_PACKAGE into a valid URL to fetch the package. Also it will set some internal variables such as HOMEPAGE or S to the correct settings. You see life can be convenient when you know how to do it. If you want to apply a bbclass you can either insert inherit foo.bbclass into each recipe or you...

Static analysis tool: cppcheck

This post shall be the start of a loose series on static code analysis tools that I've been using when professionally coding. The tools should be compared against the same code base, so that one could get an impression what the benefits and flaws of a certain tool are. Please put your questions/suggestions into the comments. Today's tool should be cppcheck . Supported Languages C C++ Dependencies (besides gcc) libprce Special features custom rules for checking can be applied as prce-compatible regular expressions Testing Under test shall be the unmodified code of busybox version 1.29.2 as to be found as yocto-poky layer at gitrev 3541f019a505d18263fad0b46b88d470e3fd9d62. As configuration for yocto the standard configuration is used. cppcheck is used in version 1.87 Number of total findings in code : 308 Number of different finding types : 26 Findings in details class vs. count nullPointer 3 memleakOnRealloc ...