[PATCH rtems-lwip v3 1/7] lwip.py: Change arch and bsp check method

[Kinsey Moore]

On 9/9/2022 16:29, Chris Johns wrote:
> On 9/9/2022 11:16 pm, Kinsey Moore wrote:
>> On 9/9/2022 01:46, Chris Johns wrote:
>>> On 9/9/2022 2:52 am, Kinsey Moore wrote:
>>>> At some point, the lwIP build needs to get better about managing which BSPs it
>>>> supports, but that's not a task for you here and now.
>>> I think this is needed. Can lwip be built generically for a BSP that is not
>>> specific covered in a list?
>> lwIP is not currently buildable for BSPs that have not been explicitly added to
>> the build. The first step would be a mostly-unified lwipopts that provides
>> defaults that are overridable by BSP-specific or possibly user-provided
>> configuration. The only reason I see to allow this is if we want to let users
>> bring their own lwIP drivers without incorporating them into the rtems-lwip
>> integration repository.
>>> I ask because lwip has been added to the RSB 6/rtems-packages and I could not
>>> build the erc32 BSP stack because lwip had an error.
>>>
>>> I am fine with lwip being in ?/rtems-packages if it can be built for every bsp
>>> at some generic level.
>> I'll look into better management of BSP-specific configuration and making a
>> generic build available for BSPs that don't have a particular configuration
>> available.
> Looking at this some more I am not sure it is needed unless lwip wants it. We
> cannot have the networking stacks in the generic package list or we end up with
> more than one built and installed at once and we do not support that.

In that case, I'll stick with the BSP management improvements once v4 of 
this patch set goes in (probably) and skip the generic build.

Is a generic build something that would be worth pursuing for lwIP? It 
would come with the core stacks, but no drivers whatsoever.


Kinsey