[rtems-bsp-builder] 2018-04-24 18:06:05: Profile(s): everything

[Joel Sherrill]

On Wed, Apr 25, 2018, 8:07 PM Chris Johns <chrisj at rtems.org> wrote:

> On 25/04/2018 17:57, Sebastian Huber wrote:
> > On 25/04/18 09:07, joel at rtems.org wrote:
> >> Failures Report
> >> ===============
> >>     1 debug epiphany/epiphany_sim build:
> >>        configure: /home/joel/rtems-work/rtems/configure
> --target=epiphany-\
> >>        rtems5 --enable-rtemsbsp=epiphany_sim --prefix=/home/joel/rtems-\
> >>        work/bsps --enable-debug
> >>       error: cpukit/mghttpd/mongoose.c:674:1: internal compiler error:
> in
> >>              epiphany_expand_prologue, at
> config/epiphany/epiphany.c:1830
> >
> > Ok, the clue is that this is built with networking enabled. This is not
> visible
> > here under "configure: ...".
>
> Are the default states considered a valid configuration or should the BSP
> builder always list the options it controls? The list is:
>
> https://git.rtems.org/rtems-tools/tree/tester/rtems/rtems-bsps.ini#n155
>
> and adding the `no-*` variant should resolve this.
>
> > This ICE is a known problem. I always build with
> > networking disabled on this platform.
>
> How do we manage this?
>
> 1. Leave networking available as a configuration for this BSP and allow the
> error? I do not like this, it is sloppy.
>

In some cases, we silently disable code for architectures know to be broken
or not supported.

>
> 2. Have configure raise an error on this arch if networking is enabled?
>

Possible. Tester still has to avoid the option.


> 3. Remove the option and always enable? Can this work with libbsd now the
> headers have moved?
>

I think it might work but i don't want to do it. I prefer the view that the
user is building a kernel. And then adds on their choice of a network
stack. I would like that to be the new stack, the Legacy stack, or ltwp.

>
> 4. Remove the networking stack to a separate repo and move in the
> examples-v2 tests?
>

Yes. Ideally and you mean network-demos.

Also have to include drivers from BSPs

>
> 5. Something else?
>

A separate Repository is the best long-term solution. It allows us to start
deemphasizing the networking stack in  the tree itself.

>
> Chris
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/build/attachments/20180426/571eb537/attachment-0002.html>