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. --joel --joel > >> Chris >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
