[PATCH] build: Export BSP base and family via pkg-config

[Joel Sherrill]

On Tue, Jul 25, 2023 at 12:19 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

>
>
> On 25.07.23 19:15, Gedare Bloom wrote:
> > On Tue, Jul 25, 2023 at 11:11 AM Sebastian Huber
> > <sebastian.huber at embedded-brains.de>  wrote:
> >>
> >>
> >> On 25.07.23 18:01, Gedare Bloom wrote:
> >>> On Tue, Jul 25, 2023 at 5:13 AM Sebastian Huber
> >>> <sebastian.huber at embedded-brains.de>   wrote:
> >>>> This allows application and library build systems to derive option
> >>>> values from the BSP base and family names.
> >>>> ---
> >>>>    spec/build/bsps/pkgconfig.yml | 2 ++
> >>>>    1 file changed, 2 insertions(+)
> >>>>
> >>>> diff --git a/spec/build/bsps/pkgconfig.yml
> b/spec/build/bsps/pkgconfig.yml
> >>>> index e08c83fe27..afaffbbf0f 100644
> >>>> --- a/spec/build/bsps/pkgconfig.yml
> >>>> +++ b/spec/build/bsps/pkgconfig.yml
> >>>> @@ -15,6 +15,8 @@ content: |
> >>>>      ABI_FLAGS=${ABI_FLAGS}
> >>>>      RTEMS_ARCH=${ARCH}
> >>>>      RTEMS_BSP=${BSP_NAME}
> >>>> +  RTEMS_BSP_BASE=${BSP_BASE}
> >>>> +  RTEMS_BSP_FAMILY=${BSP_FAMILY}
> >>> These expose a little bit of the internal working of the build system.
> >>> I think it's fine, since these two fields should not change over time.
> >>> But, it commits us to maintain this mapping and these variables.
> >> We had the RTEMS_BSP also in the old build system, but it was actually
> >> what is now the RTEMS_BSP_BASE in this patch. With the user-defined BSP
> >> names we have for:
> >>
> >> [arch/user_bsp_name]
> >> INHERIT = system_bsp_name
> >>
> >> This results in:
> >>
> >> RTEMS_BSP = user_bsp_name
> >> RTEMS_BSP_BASE = system_bsp_name
> >>
> >> Maybe we should change this to:
> >>
> >> RTEMS_BSP = system_bsp_name
> >> RTEMS_BSP_NAME = user_bsp_name
> >>
> > This would make more sense. I don't know what it might break to make
> > this change now though, as external build tools may rely on the
> > current definition of RTEMS_BSP?
>
> Yes, this is a bit tricky since the BSP name is also encoded in the *.pc
> file name: ${arch}-rtems6-{user_bsp_name}.pc. This is an argument for
> keeping RTEMS_BSP = user_bsp_name.
>

I would agree with that since that's the name the user expects and will be
part of any installed path, pkg config file, etc.

That leaves RTEMS_BSP_NAME is not great. How about RTEMS_BSP_CANONICAL?

RTEMS_BSP_FAMILY has been around a long time and should be well understood.
I certainly have explained the concept in the class for a LONG LONG time
even is
there are examples like erc32 and leon3 which overlap CPU, family, and BSP
names.
But powerpc -> motorola_shared -> mvme2100 -> user name or
arm -> xilinx-zynq -> xilinx_zynq_zedboard -> user name w/cfg do make sense.

We are encouraging users to "derive" custom BSPs based on specific
configurations
of existing ones. Makes sense to add a naming layer.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230725/4af8d226/attachment-0001.htm>