On 27/11/19 11:26 pm, Sebastian Huber wrote:
> On 27/11/2019 13:17, Hesham Almatary wrote:
>> On Wed, 27 Nov 2019 at 11:59, Sebastian Huber
>> <sebastian.hu...@embedded-brains.de> wrote:
>>> On 27/11/2019 12:49, Hesham Almatary wrote:
>>>> Hi Sebastian,
>>>>
>>>> Thanks for that great effort. I'd aim to use this build system for my
>>>> RISC-V development.
>>>>
>>>> I followed the user manual trying to build RISC-V targets and RTEMS
>>>> (aaf7f8b84) and here are a few comments:
>>>>
>>>> * .waf bsp_defaults doesn't give an error when mistyping the BSP name,
>>>> but just outputs an empty .ini file.
>>>
>>> If there is no matching BSP, then you get nothing. I think this is the
>>> right thing to do.
If the user does not enter the correct BSP name we should provide an relevant
error message on stderr and return a non-zero error code. I believe we should
not silently move past an error without a clear indication there is a problem.
>>> Doing a
>>>
>>> ./waf bsp_defaults --rtems-bsps=riscv/rv64imac_medany > bsps.ini
>>>
>>> is not a recommended use case. You should only set the necessary minimum
>>> of options.
If this documented?
>> Not sure, I only wanted to build a specific BSP variant without having
>> to build all variants. Is that not recommended?
>
> This is fine, but I would not dump all options into the config.ini, maybe
> just:
>
> [riscv/rv64imac_medany]
> COMPILER = clang
> BUILD_TESTS = True
How do you get a list of valid options and values to know what to set and not
set?
If you do not providing a value do you get your current version's default? Does
this make updating defaults in rtems.git more complicated?
>>>> * ./waf complains about not finding gcc if I don't give it the
>>>> --prefix, even though it's in my PATH
>>>
>>> Yes, this is currently the intentional behaviour. Should this be changed to
>>>
>>> conf.find_program(XYZ, path_list=tools +
>>> environ.get('PATH','').split(os.pathsep))
>>>
>>> ?
>> I think that makes sense (also for default prefix?), but it would
>> still be useful to be able to override that with --prefix to use
>> different installed toolchains if needed.
>
> Chris, what is your opinion on this?
A rigorous approach would ignore a user's path because paths are something we
are not good at maintaining and this can lead to subtle issues in a project that
are hard to figure out.
The rtems_waf behavior currently is:
1. --rtems-tools is the first path searched
2. --prefix if no --rtems-tools
3. $PATH if no --rtems-tools and no --prefix
I am fine with rtems.git's waf doing the same thing.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
