[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