New Build System Status

[Chris Johns]

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.huber at 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