On Tue, Jul 25, 2023 at 12:19 PM Sebastian Huber < sebastian.hu...@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.hu...@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.hu...@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.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel