[PATCHv2 rtems_waf] Allow vendor field in toolchain target triplet

martinerikwerner.aac at gmail.com martinerikwerner.aac at gmail.com
Fri May 26 16:03:37 UTC 2023


On Fri, 2023-05-26 at 08:33 +1000, Chris Johns wrote:
> On 25/5/2023 6:53 pm, martinerikwerner.aac at gmail.com wrote:
> > While poking around some more, it seems like there's more places in
> > this file where assumptions of no vendor in the triplet might come
> > into
> > play (but did not affect my use of it), if I'm reading it
> > correctly?:
> > 
> > 227         conf.env.ARCH_BSP = '%s/%s' % (arch.split('-')[0], bsp)
> > 
> > 232         conf.env.RTEMS_ARCH = arch.split('-')[0]
> > 
> > 554     return _arch_from_arch_bsp(arch_bsp).split('-')[0]
> > 
> > 931         ab = arch_bsp.split('-')
> > (...)
> > 939         flagstr = subprocess.check_output(
> > 940             [config, '--bsp',
> > 941              '%s/%s' % (ab[0], ab[2]), flags_map[flags]])
> > 
> > I'm also a bit uncertain, what is the "arch" actually supposed to
> > be in
> > general, given that the _arch_from_arch_bsp(arch_bsp) and
> > arch(arch_bsp) seem to disagree (former include the os (rtems)
> > field,
> > latter excludes it).
> 
> I suspect the uncertainly is due to things evolving and me not paying
> close
> enough attention because it did not matter. The vendor field changes
> that. I
> will take a look and see if I can clean it up.
> 
> What is the full text for the `arch_bsp` you are working with so I
> can test it?

waf gives the following if I instrument the rtems.py code:

  arch_bsp: sparc-gaisler-rtems5-leon3

This is based on a minimal application with the rtems_waf submodule
(c721249+instrumentation) and pointing at a downloaded rcc-1.3.1-gcc
toolchain and bsp:

  ./waf configure --rtems=$HOME/binary/rcc-1.3.1-gcc --rtems-bsps=sparc-gaisler/leon3


More information about the devel mailing list