On Sun, 4 May 2025 at 07:27, Heinrich Schuchardt
<heinrich.schucha...@canonical.com> wrote:
>
>
>
> Simon Glass <s...@chromium.org> schrieb am Sa., 3. Mai 2025, 23:27:
>>
>> Hi Heinrich,
>>
>> On Sat, 3 May 2025 at 07:32, Heinrich Schuchardt
>> <heinrich.schucha...@canonical.com> wrote:
>> >
>> > In some cases we have alternative configuration options that supply the
>> > same functionality, e.g CONFIG_NET and CONFIG_NET_LWIP.
>> >
>> > Allow to specify all of them as arguments for buildconfigspec() and execute
>> > the text if any of these is fulfilled, e.g.
>> >
>> >     @pytest.mark.buildconfigspec('net', 'net_lwip')
>> >
>> > Update the documentation.
>> >
>> > Signed-off-by: Heinrich Schuchardt <heinrich.schucha...@canonical.com>
>> > ---
>> >  doc/develop/py_testing.rst | 24 ++++++++++++++++++++++++
>> >  test/py/conftest.py        | 10 +++++++---
>> >  2 files changed, 31 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/doc/develop/py_testing.rst b/doc/develop/py_testing.rst
>> > index 217ae447035..7dbed8833bf 100644
>> > --- a/doc/develop/py_testing.rst
>> > +++ b/doc/develop/py_testing.rst
>> > @@ -514,3 +514,27 @@ of the `ubman.config` object, for example
>> >  Build configuration values (from `.config`) may be accessed via the 
>> > dictionary
>> >  `ubman.config.buildconfig`, with keys equal to the Kconfig variable
>> >  names.
>> > +
>> > +A required configuration setting can be defined via a buildconfigspec()
>> > +annotation. The name of the configuration option is specified in lower 
>> > case. The
>> > +following annotation for a test requires CONFIG_EFI_LOADER=y:
>> > +
>> > +.. code-block:: python
>> > +
>> > +    @pytest.mark.buildconfigspec('efi_loader')
>> > +
>> > +Sometimes multiple configuration option supply the same functionality. If
>> > +multiple arguments are passed to buildconfigspec(), only one of the
>> > +configuration options needs to be set. The following annotation requires 
>> > that
>> > +either of CONFIG_NET or CONFIG_NET_LWIP is set:
>> > +
>> > +.. code-block:: python
>> > +
>> > +    @pytest.mark.buildconfigspec('net', 'net lwip')
>> > +
>> > +The notbuildconfigspec() annotation can be used to require a configuration
>> > +option not to be set. The following annotation requires CONFIG_RISCV=n:
>> > +
>> > +.. code-block:: python
>> > +
>> > +    @pytest.mark.notbuildconfigspec('riscv')
>> > diff --git a/test/py/conftest.py b/test/py/conftest.py
>> > index 5aea85647af..6c3ac67979a 100644
>> > --- a/test/py/conftest.py
>> > +++ b/test/py/conftest.py
>> > @@ -711,9 +711,13 @@ def setup_buildconfigspec(item):
>> >      """
>> >
>> >      for options in item.iter_markers('buildconfigspec'):
>> > -        option = options.args[0]
>> > -        if not ubconfig.buildconfig.get('config_' + option.lower(), None):
>> > -            pytest.skip('.config feature "%s" not enabled' % 
>> > option.lower())
>> > +        nomatch = True
>> > +        for arg in options.args:
>> > +            if ubconfig.buildconfig.get('config_' + arg.lower(), None):
>> > +                nomatch = False
>> > +        if nomatch:
>> > +            argsString = ', '.join(options.args)
>> > +            pytest.skip(f'.config features "{argsString}" not enabled')
>> >      for options in item.iter_markers('notbuildconfigspec'):
>> >          option = options.args[0]
>> >          if ubconfig.buildconfig.get('config_' + option.lower(), None):
>> > --
>> > 2.48.1
>> >
>>
>> I ran into this problem too. Would it be possible to have CONFIG_NET
>> mean that we have networking (either option) and CONFIG_LWIP mean that
>> it is lwip? The current Kconfig seems a bit broken to me....
>>
>> Regards,
>> Simon
>
>
> Hello Simon,
>
> Yes, we can think about reworking the network configuration in a future 
> series.
>
> E.g. have as choice
>
> * CONFIG_NET_LEGACY
> * CONFIG_NET_LWIP
> * CONFIG_NET_NONE
>
> and CONFIG_NET := !CONFIG_NONE
>
> But I think it is still valuable in its own right to be able to express a 
> logical OR when defining test dependencies.
>

Yes OK

Reviewed-by: Simon Glass <s...@chromium.org>

> Best regards
>
> Heinrich
>

Reply via email to