New Build System Status

[Joel Sherrill]

On Wed, Nov 27, 2019 at 6:26 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> 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. 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.
> >>
> > 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
>
> >
> >>> * ./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?
>

I think the PATH should be honored unless a tools path option is specified.


>
> >
> >>
> >>> * dltests fail to build on RISC-V when BUILD_TESTS = True
> >>
> >> Yes, this is work in progress. I should work now.
> >>
> > Thanks.
> >
> >>> * Can't find  any "*.exe" after a default build:
> >>
> >> Ok, this is a bug, you should find the samples.
> >>
> > Is it reproducible?
>
> I will have a look at this later.
>
> >
> >>> * Can't notice a difference when I pass rtems-compiler=clang, it still
> >>> builds with gcc.
> >>
> >> You have to set the compiler in the config.ini file, see latest user
> >> documentation:
> >>
> > Thanks it works fine when I add the flag to config.ini. Is
> > rtems-compiler=clang useless this way?
>
> This option is useful to get the default values depending on the
> selected compiler, see example in:
>
> >
> >> https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf
> >>
> >>
> >> --
> >> Sebastian Huber, embedded brains GmbH
> >>
> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> >> Phone   : +49 89 189 47 41-16
> >> Fax     : +49 89 189 47 41-09
> >> E-Mail  : sebastian.huber at embedded-brains.de
> >> PGP     : Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191127/53b075fe/attachment-0001.html>