Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: buildroot@busybox.net
Subject: [Buildroot] Synchronisation of dependencies between Config.in and .mk files ?
Date: Mon, 27 Oct 2008 18:07:10 -0600	[thread overview]
Message-ID: <fa686aa40810271707p3268e831rd4173303aecc6dcd@mail.gmail.com> (raw)
In-Reply-To: <e4c675870810271533q21914df7od498b0be858600e2@mail.gmail.com>

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.

  parent reply	other threads:[~2008-10-28  0:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-27 16:56 [Buildroot] Synchronisation of dependencies between Config.in and .mk files ? Thomas Petazzoni
2008-10-27 17:32 ` Roberto A. Foglietta
2008-10-27 18:43 ` Peter Korsgaard
2008-10-27 20:11   ` Thomas Petazzoni
2008-10-27 20:32     ` Peter Korsgaard
2008-10-27 20:46       ` Roberto A. Foglietta
2008-10-27 21:47     ` Markus Heidelberg
2008-10-27 22:33       ` Roberto A. Foglietta
2008-10-27 23:26         ` Markus Heidelberg
2008-10-28  0:07         ` Grant Likely [this message]
2008-10-28  7:32         ` Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa686aa40810271707p3268e831rd4173303aecc6dcd@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox