How to choose between contrib and build recipe in RSB?

Tools Source Builder
1

When integrating third party software with rtems, there are two options you can choose from:

  1. add the sources directly to contrib
  2. add a build recipe to RSB

I want to understand when you choose one over the other. My initial guess is that when you want to modify the sources, you choose contrib. But then again, there is also the option of applying patches to RSB builds, so I am confused about which path to take. Any clarification would help

2

The short version is code in /contrib/ are not optional to RTEMS for the specific item you are building. If you are building a BSP there are required files those would go into /contrib/ if they are required and 3rd party.

Anything in the RSB is going to be optional outside of the tooling. You can choose to build it.

That’s just a general rule for example if it’s something most people will want no matter what it’s better to have it in /contrib/ than force them to always build it via the RSB.

That’s essentially it but you also missed a 3rd option which is to make it a ‘package’ like libbsd.

3

To clarify, libbsd is also built through the RSB. There is also a packaging concept, search for “rtems-package” in the RSB to see how that is used. The libbsd is built a bit differently than the packages that use rtems-package so we should be careful with the terminology, but either way it is done through the RSB.

4

Amar’s points about optional vs not are a good rule of thumb. Basically, if the third-party software is used within rtems.git, then it has to be available at build-time either in the tree or through the compiler toolchain.

Other considerations might include:

  • Legacy code. If the software was already in the rtems.git tree, then it is sensible to keep it there, or at least to move it to contrib before considering moving it to an RSB recipe.
  • Modifications for RTEMS: If the software needs to be patched or adapted for RTEMS, having it in the tree with test cases makes it easier to ensure the patched behavior continues to work into the future.
5

Great point re: legacy. We’re looking at eventually moving HALs to the RSB and not having them in RTEMS at all for example as they change too rapidly.

I should have mentioned the patching part that’s also a great point it lets us track these changes accordingly where for the most part HALs are untouched.

6

That clears it, thank you!