[PATCHv2 rtems_waf] Allow vendor field in toolchain target triplet
Chris Johns
chrisj at rtems.org
Sat May 27 07:57:24 UTC 2023
On 27/5/2023 2:03 am, martinerikwerner.aac at gmail.com wrote:
> 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
Thanks
Chris
More information about the devel
mailing list