[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Thomas Petazzoni]

Hi,

Currently, there are two complementary ways of expressing dependencies
between packages:

 * Through the select BR2_FOOBAR statements in the Config.in files ;

 * Through the FOOBAR_DEPS variable in the package makefiles.

The second one is absolutely necessary, as it makes sure that packages
are built in the proper order. The first one allows packages Makefiles
to adapt their configuration depending on the existing dependencies
(i.e if tslib is available, then enable support for touchscreens, etc.).

However, there are great chances for these two lists of dependencies
for each package to become unsynchronized.

What's the policy about this ? What are the current techniques to keep
them synchronized ?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Roberto A. Foglietta]

2008/10/27 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Hi,
>
> Currently, there are two complementary ways of expressing dependencies
> between packages:
>
>  * Through the select BR2_FOOBAR statements in the Config.in files ;
>

 Good: because we can see in the menuconfig what is selected immediately
 Bad: because once we remove the initial package we still stay with dependencies

>  * Through the FOOBAR_DEPS variable in the package makefiles.
>


 Bad: because these dependencies are not displayed into menuconfig
 Bad: because these dependencies would not be downloaded in 'make
sources' <--- !!!
 Good: because these dependencies are necessary for building


> The second one is absolutely necessary, as it makes sure that packages
> are built in the proper order. The first one allows packages Makefiles
> to adapt their configuration depending on the existing dependencies
> (i.e if tslib is available, then enable support for touchscreens, etc.).
>
> However, there are great chances for these two lists of dependencies
> for each package to become unsynchronized.
>
> What's the policy about this ? What are the current techniques to keep
> them synchronized ?
>

  tristate,  where x means depend on something:

BR2_CIAO=y
BR2_CIAO=x
# BR2_CIAO is not set

 or

BR2_CIAO=y
# BR2_CIAO needed by BR2_PLUTO BR2_PAPERINO ...
# BR2_CIAO is not set

 'select' in Config.in should not exist and 'make' should generate at
run-time all 'x-select' constrains accordingly with dependencies in
package.mk

 Easy to say but...
 ;-)

 Cheers,
-- 
/roberto

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> However, there are great chances for these two lists of
 Thomas> dependencies for each package to become unsynchronized.

True, but I don't think there's any easy way of going from Kconfig
selects to Makefile deps.

 Thomas> What's the policy about this ? What are the current
 Thomas> techniques to keep them synchronized ?

Well, the policy is that they should be in sync - And we currently
have no way of ensuring that they are in sync besides manual review.

Do you have any ideas about how to solve this in a nicer way?

-- 
Bye, Peter Korsgaard

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Thomas Petazzoni]

Le Mon, 27 Oct 2008 19:43:07 +0100,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> Do you have any ideas about how to solve this in a nicer way?

Not really. Maybe the Config.in read by kconfig could be generated by
the Makefile system. Either completely from the Makefiles, or from
Config.in.tmp files, parsed and modified to contain the dependencies.

However, there are some packages with optional dependencies, like in
matchbox:

ifeq ($(strip $(BR2_PACKAGE_X11R7_LIBXCOMPOSITE)),y)
ifeq ($(strip $(BR2_PACKAGE_X11R7_LIBXPM)),y)
  MATCHBOX_WM_OPTS+=--enable-composite
  MATCHBOX_WM_DEPS+=xlib_libXcomposite
  MATCHBOX_WM_DEPS+=xlib_libXpm
  MATCHBOX_LIB_DEPS+=xlib_libXpm
endif
endif

I'm not sure how to handle that kind of case.

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Le Mon, 27 Oct 2008 19:43:07 +0100,
 Thomas> Peter Korsgaard <jacmet@uclibc.org> a ?crit :

 >> Do you have any ideas about how to solve this in a nicer way?

 Thomas> Not really. Maybe the Config.in read by kconfig could be
 Thomas> generated by the Makefile system. Either completely from the
 Thomas> Makefiles, or from Config.in.tmp files, parsed and modified
 Thomas> to contain the dependencies.

 Thomas> However, there are some packages with optional dependencies,
 Thomas> like in matchbox:

I'm also not sure all packages use exactly the same make symbol and
BR2_PACKAGE_<symbol> - Personally I don't think it's worth the effort.

-- 
Bye, Peter Korsgaard

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Roberto A. Foglietta]

2008/10/27 Peter Korsgaard <jacmet@uclibc.org>:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
>  Thomas> Le Mon, 27 Oct 2008 19:43:07 +0100,
>  Thomas> Peter Korsgaard <jacmet@uclibc.org> a ?crit :
>
>  >> Do you have any ideas about how to solve this in a nicer way?
>
>  Thomas> Not really. Maybe the Config.in read by kconfig could be
>  Thomas> generated by the Makefile system. Either completely from the
>  Thomas> Makefiles, or from Config.in.tmp files, parsed and modified
>  Thomas> to contain the dependencies.
>
>  Thomas> However, there are some packages with optional dependencies,
>  Thomas> like in matchbox:
>
> I'm also not sure all packages use exactly the same make symbol and
> BR2_PACKAGE_<symbol> - Personally I don't think it's worth the effort.
>

 A script which make people remember to keep those things synchronized?

 Without this synchronization 'make source' is broken.

 Cheers,
-- 
/roberto

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Markus Heidelberg]

Thomas Petazzoni, 27.10.2008:
> Le Mon, 27 Oct 2008 19:43:07 +0100,
> Peter Korsgaard <jacmet@uclibc.org> a ?crit :
> 
> > Do you have any ideas about how to solve this in a nicer way?
> 
> Not really. Maybe the Config.in read by kconfig could be generated by
> the Makefile system. Either completely from the Makefiles, or from
> Config.in.tmp files, parsed and modified to contain the dependencies.

When reading it from the Makefiles, you couldn't automatically decide whether
to use "select" or "depends on", because in the Makefile there is no
difference between them.

Markus

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Roberto A. Foglietta]

2008/10/27 Markus Heidelberg <markus.heidelberg@web.de>:
> Thomas Petazzoni, 27.10.2008:
>> Le Mon, 27 Oct 2008 19:43:07 +0100,
>> Peter Korsgaard <jacmet@uclibc.org> a ?crit :
>>
>> > Do you have any ideas about how to solve this in a nicer way?
>>
>> Not really. Maybe the Config.in read by kconfig could be generated by
>> the Makefile system. Either completely from the Makefiles, or from
>> Config.in.tmp files, parsed and modified to contain the dependencies.
>
> When reading it from the Makefiles, you couldn't automatically decide whether
> to use "select" or "depends on", because in the Makefile there is no
> difference between them.

 Reading/including only those .mk for which packages has been selected
and the meaning became always: 'select'

 I think the use of "depends on" in Config.in should be used ONLY when
arch restrictions have been involved.

 Example: I need nfs but nfs 'depends on' rpc... the first time in the
menuconfig I will waste minutes to understand I have to select rpc in
order to select nfs, why? If I want a cold beer I ask for a cold beer.
Why I have to ask "do you have the freezer pluged in", before? It is
obvious that a freezer is needed for a cold beer but it is not obvious
asking for a freezer when you are looking for a beer.


 Cheers,
-- 
/roberto

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Markus Heidelberg]

Roberto A. Foglietta, 27.10.2008:
> 2008/10/27 Markus Heidelberg <markus.heidelberg@web.de>:
> > When reading it from the Makefiles, you couldn't automatically decide whether
> > to use "select" or "depends on", because in the Makefile there is no
> > difference between them.
> 
>  Reading/including only those .mk for which packages has been selected
> and the meaning became always: 'select'
> 
>  I think the use of "depends on" in Config.in should be used ONLY when
> arch restrictions have been involved.

Definitely not. For example sdl_image depends on sdl instead of selecting it.
So you can have a hierarchical menu in Config.in and hide all the sdl_
packages unless sdl is not activated. Of course this is only possible for
packages in direct relation to each other.

>  Example: I need nfs but nfs 'depends on' rpc... the first time in the
> menuconfig I will waste minutes to understand I have to select rpc in
> order to select nfs, why? If I want a cold beer I ask for a cold beer.
> Why I have to ask "do you have the freezer pluged in", before? It is
> obvious that a freezer is needed for a cold beer but it is not obvious
> asking for a freezer when you are looking for a beer.

There are settings that probably shouldn't be selected automatically, for
example such which require a recompilation of the toolchain. In this case
there could also be a "comment NFS needs RPC" in the Config.in. But I think
that is hard to decide, there shouldn't be too much comments in menuconfig.

Markus

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Grant Likely]

On Mon, Oct 27, 2008 at 4:33 PM, Roberto A. Foglietta
<roberto.foglietta@gmail.com> wrote:
> 2008/10/27 Markus Heidelberg <markus.heidelberg@web.de>:
>> Thomas Petazzoni, 27.10.2008:
>>> Le Mon, 27 Oct 2008 19:43:07 +0100,
>>> Peter Korsgaard <jacmet@uclibc.org> a ?crit :
>>>
>>> > Do you have any ideas about how to solve this in a nicer way?
>>>
>>> Not really. Maybe the Config.in read by kconfig could be generated by
>>> the Makefile system. Either completely from the Makefiles, or from
>>> Config.in.tmp files, parsed and modified to contain the dependencies.
>>
>> When reading it from the Makefiles, you couldn't automatically decide whether
>> to use "select" or "depends on", because in the Makefile there is no
>> difference between them.
>
>  Reading/including only those .mk for which packages has been selected
> and the meaning became always: 'select'
>
>  I think the use of "depends on" in Config.in should be used ONLY when
> arch restrictions have been involved.
>
>  Example: I need nfs but nfs 'depends on' rpc... the first time in the
> menuconfig I will waste minutes to understand I have to select rpc in
> order to select nfs, why? If I want a cold beer I ask for a cold beer.
> Why I have to ask "do you have the freezer pluged in", before? It is
> obvious that a freezer is needed for a cold beer but it is not obvious
> asking for a freezer when you are looking for a beer.

However, IIRC "select" in Kconfig is dangerous because it completely
overrides the dependencies on the option being force selected.  There
are technical issues with select and it must be used with caution.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[Buildroot] Synchronisation of dependencies between Config.in and .mk files ?

[Peter Korsgaard]

>>>>> "Roberto" == Roberto A Foglietta <roberto.foglietta@gmail.com> writes:

Hi,

 Roberto>  I think the use of "depends on" in Config.in should be used
 Roberto> ONLY when arch restrictions have been involved.

We normally only use depends on for sub packages (E.G. X applications
that don't make any sense without X) and for toolchain dependencies
(E.G. locale support) as changing toolchain option with select isn't a
good thing.


-- 
Bye, Peter Korsgaard