[Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism

Yann E. MORIN yann.morin.1998 at free.fr
Tue Oct 16 17:34:53 UTC 2012


Arnout, Thomas, All,

On Tuesday 16 October 2012 Arnout Vandecappelle wrote:
> On 14/10/12 19:38, Thomas Petazzoni wrote:
> > In other words: we can assume the user knows about big subsystems
> > (X.org, Python, Perl, etc.), but we don't want him to know the fine
> > details of the dependencies on sub-options.
> 
>   Someone (I don't remember who) proposed to stop doing that, because it adds
> little value.  Indeed, it's not as if 9 extra entries in the Scripting
> Languages menu will suddenly make it more difficult to navigate.  Maybe X.org
> is an exception, but even there most packages are collected in the x11r7 menus
> (and those could still be kept in a conditional).
> 
>   Originally I was in favour of having the BR2_PACKAGE_PYTHON conditionals,
> but it _would_ probably make life simpler if we only had dependencies on
> toolchain options...
> 
>   Yann, what do you think, would it make suboption handling simpler if there
> was no 'depends on BR2_PACKAGE_PYTHON'?

In fact, I think python modules _should_ depends on BR2_PACKAGE_PYTHON, and
that should be more easily handled when _AVAILABLE is, well, available.

The problem with python modules is that they are hidden behind a
    if BR2_PACKAGE_PYTHON
    source [python-modules]
    endif
*in* *addition* *of*, for each package:
    depends on BR2_PACKAGE_PYTHON

I think the "if BR2_PACKAGE_PYTHON" should be removed, and we should keep
only the per-package depends on. If/when we add _AVAILABLE, it will be
easier to manage.

Yes, that will add more entries in the menuconfig. But that's not as it were
not already a bit crowded... ;-) And it can go in a sub-menu, anyway, like:

    Interpreters  --->
        Python support  --->
           [ ] Python
           External python modules  --->
               [ ] Foo

When you select python:

    Interpreters  --->
        Python support  --->
           [*] Python
           python module format (.pyc only)
           Core python modules  --->
               [ ] Bar
           External python modules  --->
               [ ] Foo

And when you select Foo:

    Interpreters  --->
        Python support  --->
           -*- Python
           python module format (.pyc only)
           Core python modules  --->
               [ ] Bar
           External python modules  --->
               [*] Foo


The most problematic issue I've encountered is with X11r7. The top-level
config option is BR2_PACKAGE_XORG7, but it is *not* a package.

What I would suggest is something like (just out of my tired brain):

    choice
        prompt "X Window System server type"

    config BR2_PACKAGE_XSERVER_none
        bool "None"
    
    config BR2_PACKAGE_XSERVER_xorg  # <-- Note how it currently is lower-case
        bool "Modular X.org"         #     'xorg' in the repository...
        depends on BR2_PACKAGE_XSERVER_xorg_AVAILABLE
        select BR2_HAS_XORG7
    
    comment 'X.org requires largefile and C++ support'
        depends on !BR2_PACKAGE_XSERVER_xorg_AVAILABLE
    
    config BR2_PACKAGE_XSERVER_tinyx  # <-- Ditto lower-case 'tinyx'...
        bool "TinyX"
        depends on BR2_PACKAGE_XSERVER_tinyx_AVAILABLE
        select BR2_HAS_XORG7
    
    comment 'TinyX depends on BLABLA'
        depends on !BR2_PACKAGE_XSERVER_xorg_AVAILABLE
    
    endchoice

    config BR2_HAS_XORG7
        bool

    menu "Xorg7 libs and apps"
    source "package/Xfoo/Config.in"
    # source other packages, too
    endmenu

And then in package Xfoo:

    config BR2_PACKAGE_XFOO_AVAILABLE
        def_bool y
        depends on BR2_HAS_XORG7
        depends on BR2_PACKAGE_BAR_AVAILABLE

    comment "Package Xfoo requires an Xserver"
        depends on !BR2_PACKAGE_XFOO_AVAILABLE

    config BR2_PACKAGE_XFOO
        bool "Xfoo"
        depends on BR2_PACKAGE_XFOO_AVAILABLE
        select BR2_PACKAGE_BAR

And so on...

Of course, it goes against the mantra:
    I know I want package 'Xfoo', just select whatever
    I need to get it, for ${DEITY_NAME}'s sake!

It should probably be possible to keep that semantic, yet with a bit more
involvement.

Comments?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'


More information about the buildroot mailing list