On Fri, 2023-05-26 at 08:33 +1000, Chris Johns wrote: > On 25/5/2023 6:53 pm, martinerikwerner....@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel