Conversion of BSP config files to pkg-config files

Chris Johns chrisj at
Wed Feb 20 22:25:45 UTC 2019

On 21/2/19 7:29 am, Vijay Kumar Banerjee wrote:
> On Tue, 22 Jan 2019 at 06:30, Chris Johns <chrisj at
> <mailto:chrisj at>> wrote:
>     On 21/1/19 10:46 pm, Vijay Kumar Banerjee wrote:
>     >
>     > I want to work on the ticket #3302 <> as a
>     > summer project.
>     Great.
>     > The goal of the project is to convert the BSP cfg files from `make` format
>     to the
>     > pkg-config (.pc) format.
>     The goal is to be able to *create* complete and useful .pc files. I am not sure
>     if the RTEMS build system could be turned around to use .pc, it may, but until
>     then I suggest we convert the .cfg files in the BSPS to .pc files.
>     > The approach would be to first make all the flags and
>     > Makefile macros used in the bsp .cfg files, consistent. Since the problem is
>     > complex and a huge number of files are there to deal with, I'll first manually
>     > look into a few bsps and then move forward to write a parser in python
>     > to parse and compare the .cfg files of different BSPs. Once we get a
>     consistent
>     > format for the .cfg files, we'll move on to generate the .pc files for the
>     bsps.
>     This seems like a sensible approach.
>     > I seek some guidance and discussion on the project to get started with it.
>     I think the first step is to look at the existing .cfg files and to see what is
>     happening. It will take time and is a bit boring but I feel you will quickly see
>     which ones have major differences. I lot of files are copies so I suspect they
>     will fall into patterns or groups.
> Hi,
> Sorry for the delay in starting with this. 
> I went through a few BSP cfg files, for example, the leon3
> Are we planning to write something like this for each BSPs ? ...

I hope not. The existing file would need to modified as a result of
what is needed to support the various BSPs. More below.

> =================
> prefix=@prefix@                
> exec_prefix=@exec_prefix@      
> libdir=@libdir@                
> includedir=@includedir@        
> CFLAGS=@CFLAGS@                
> Name: @RTEMS_BSP@
> Version: @VERSION@             
> Description: RTEMS BSP @RTEMS_BSP@ config
> Libs:
> Cflags: -O2 -g -ffunction-sections -fdata-sections
> =================
> every BSP configuration file includes default.cfg, how will this be
> included in the *.pc files? 

I may have not been clear in my previous reply.

The outcome of this project does not update the RTEMS build system to internally
use .pc files. The outcome is to create a complete .pc file when the BSP is
built that is installed so a user can access it to get the BSP build configuration.

This means the way the RTEMS build system reads the .cfg stays as is. The here will need to change ...

and how this is converted to a .pc file is here ...

What are the possible paths we could take? Which is the simplest or best, or is
it a mix of a few? We need to make sure all the data needed is captured, it is
usable clean fit when accessed as a user via pkg-config and, is simple to add to
RTEMS. Some ideas, there must be more, are ...

1. Examine each BSP .cfg and see if the values can be simplified into a common
set. This means the template is a single standard template for all BSPs.

2. Create a per BSP file for BSPs that _have_ extra fields and in that
file add the needed values. Append the BSP fragment to the template and
then process. This is a per BSP solution where a .pc file may have or may not
have specific fields.

I suspect we may need some or both of these options. For example any clean up
for 1) should be done, and 2) seems reasonable as a user needs to post process
the executable ELF to be target ready so will know what extra flags they need.

We should aim to update the User Manual with all settings for the BSPs.


More information about the devel mailing list