[PATCH] build: Add the BSP family to the enable set

[Joel Sherrill]

On Wed, Jul 21, 2021, 5:49 PM Chris Johns <chrisj at rtems.org> wrote:

> On 22/7/21 8:35 am, Joel Sherrill wrote:
> > On Wed, Jul 21, 2021 at 2:10 PM Sebastian Huber
> > <sebastian.huber at embedded-brains.de> wrote:
> >>
> >> On 21/07/2021 21:05, Gedare Bloom wrote:
> >>>>> The problem is that one BSP which supports SMP "riscv/griscv" is
> identical to
> >>>>> the family "riscv/griscv" which contains BSPs which do not support
> SMP
> >>>>> ("riscv/grv32i" and riscv/grv32im").
> >>>> Hmm, tricky. Can the BSPs that do not support SMP disable SMP in the
> BSP
> >>>> specific config, ie override/specialise in the BSP?
> >>>>
> >>> Or, can we avoid having duplication between BSP names and family names?
> >>
> >> Yes, good idea. We could use a "family/" prefix for example
> >> ("family/<arch>/<bsp-family-name>").
>
> Great idea.
>
> > Ideally we would never have a family and BSP variant have the same name.
> > But that rule is violated multiple times now.
>
> Yeap.
>
> > I am not sure where your triple is intended to be used but we have used
> > the pattern arch/BSP which is really <arch>/<bsp_variant> as the
> > full name of BSPs.
> >
> > If we want to step that further, we could do something similar to the
> > GNU target triple where the middle component is a rarely used vendor.
> > <arch>/<bsp_family>/<bsp_variant>.
>
> I think we are to late for this because the spec file format follows what
> I did
> in the eco-system and I would prefer we maintained a single unified way of
> doing
> this than changing it.
>
> > In recent history, there was an issue of BSP variant names needing to
> > be unique across all architectures. This may also need to apply to bsp
> > family names.
>
> What about "bsps/<family>". This means you have:
>
> powerpc/mvme2307
> bsps/motorola_powerpc
>

Is the first line is our BSP formal naming pattern and the second is how
families are named, that should be ok.

Rules for uniqueness apply.



> It is simple and clean.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210721/da025909/attachment-0001.html>