On Wed, May 16, 2018 at 9:41 AM, Joel Sherrill <j...@rtems.org> wrote: > > > On Wed, May 16, 2018 at 6:32 AM, Joel Sherrill <j...@rtems.org> wrote: >> >> >> >> On Wed, May 16, 2018, 4:05 AM Chris Johns <chr...@rtems.org> wrote: >>> >>> On 15/5/18 3:39 am, Joel Sherrill wrote: >>> > On Mon, May 14, 2018, 10:16 AM Gedare Bloom <ged...@rtems.org >>> > <mailto:ged...@rtems.org>> wrote: >>> > >>> > This is an excellent rule. BSP names should be unique. >>> > >>> > I am not sure the current logic ensures that but it did break one of my >>> > name reuses. >>> >>> I did not intend to change this. >> >> >> I didn't think you did but it is an ok rule. > > > Adding to that simple response. > > Historically, this rule was implicitly in place for the entire period that > the .cfg > files were in make/custom at the top of the tree. It was only when they > moved > under libbsp/ and now bsps/, that this is even a possibility. I suppose the > BSP family directories would have been ok to duplicate. > > During the period while it was possible for two BSP variants to have the > same > name, the .cfg files still installed into ${prefix}/make/custom. So the last > BSP > installed won. I think duplicate BSP family names would have worked. > > In the long history of RTEMS, I think I am the only person who managed to > name BSPs in different architectures the same. I suppose it would be > tempting > to do the same with gdb or qemu BSPs, but qemu has so many variants that > it wouldn't make sense there. I named the BSP families and variants "deos" > since the paravirtualized RTEMS is hosted on Deos. > > The test for valid BSP is based on wildcard'ing for linkcmds. If BSP > families > have the same name in multiple architectures, it will find an arbitrary one. > That's what tripped me up. > > We need to have a rule for BSP family directories and BSP variants. At this > point, I have unique BSP variants (e.g. deos_x86, deos_ppc, etc) and the > BSP family name is deos on all three architectures. This does work. > > I am OK with whatever decision we make. We just need to be conscious > of it, document it somewhere (Coding Conventions, BSP Guide) and note > where it needs to be enforced in the build system. >
BSP guide should be sufficient user docu. > --joel > > --joel > > > > >>> >>> >>> Chris > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel