Building BSP bset without including Tools

Chris Johns chrisj at
Thu Oct 1 03:46:27 UTC 2020

On 1/10/20 1:51 am, Joel Sherrill wrote:
> Is it possible to build a BSP bset and not build the tools? I know it is
> convenient for a user focused on a single BSP but since each bset builds the
> toolchain, it would be nice to have a way to package tools and a collection of
> BSPs for the same target. 

Great question, thank you.

Who would use a complete set of BSPs for an architecture?

> Is there a without option for this?

There is no option.

> If not, suggestions on how to add one? 

I think we are better served by a different approach. What you are asking for is
a custom deployment or a specialised deployment.

I suggest you create the build sets you need. These do not need to be in the RSB
source tree. They could in a private repo that has the RSB as a submodule or you
could fetch a release tarball of the RSB and use that.

If there is value in the build sets for better vertical integration we can
review them and then merge them into the RSB repo.

If you look in the BBB build set ...

... you can see the vertical stack of software built:


You could move the last three build sets to a file called
`rtems/config/bsps/net.bset`. The contents would be:


and then update the BSP files that have that stack to `bsps/net`. You could also
add another build set `rtems/config/bsps/bsp.bset` that is:


for those BSPs libbsd will not build for. I think packages will still build
without libbsd being built and if that is not true maybe split packages?

To support a number of BSPs you would need to create a build set for each BSP.
Something like `rtems/config/bsps/bsp/erc32.bset` (note the extra directory):

%define with_rtems_bsp erc32
%define rtems_target   sparc-rtems%{rtems_version}
%define rtems_host     %{rtems_target}


and then you could have `rtems/config/bsps/sparc.bset`:


The `bsp` subdirectory is an attempt to try and group these files to avoid
confusion with what we have now:


and then we add:


I am concerned about there being some confusion. If you can think of better
naming that helps please say so.


More information about the devel mailing list