From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Date: Mon, 27 Oct 2008 18:07:10 -0600 Subject: [Buildroot] Synchronisation of dependencies between Config.in and .mk files ? In-Reply-To: References: <20081027175645.7e7cb096@surf> <87zlkphoas.fsf@macbook.be.48ers.dk> <20081027211141.0935d9c0@surf> <200810272247.34068.markus.heidelberg@web.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net On Mon, Oct 27, 2008 at 4:33 PM, Roberto A. Foglietta wrote: > 2008/10/27 Markus Heidelberg : >> Thomas Petazzoni, 27.10.2008: >>> Le Mon, 27 Oct 2008 19:43:07 +0100, >>> Peter Korsgaard 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.