kbuild question

kbuild question

[Kumar Gala]

I was wondering if there was some way to make a Kconfig menu either  
be just a menu or a choice depending on another bool being set or not.

What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I  
want it so you can only select on option, however if  
CONFIG_ONLY_HAVE_ONE is not set you should be able to select multiple  
options.

thanks

- k

Re: kbuild question

[Sam Ravnborg]

On Thu, Feb 15, 2007 at 01:18:52PM -0600, Kumar Gala wrote:
> I was wondering if there was some way to make a Kconfig menu either  
> be just a menu or a choice depending on another bool being set or not.
> 
> What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I  
> want it so you can only select on option, however if  
> CONFIG_ONLY_HAVE_ONE is not set you should be able to select multiple  
> options.

You can do so using if.
See following example:
--------------------------------------------------------------
config ONLY_HAVE_ONE
	prompt "only have one?"
	boolean

if ONLY_HAVE_ONE
config FOO
	bool foo
	default y
endif

if !ONLY_HAVE_ONE
choice
	prompt "multiple values"
	default VAL_FIRST

config VAL_FIRST
	bool "First value"

config VAL_SECOND
	bool "Second value"
endchoice

endif
--------------------------------------------------------------

You should be able to modify this for the usage you ask for.

Hope this is useful,

	Sam

Re: kbuild question

[Kumar Gala]

On Feb 15, 2007, at 4:33 PM, Sam Ravnborg wrote:

> On Thu, Feb 15, 2007 at 01:18:52PM -0600, Kumar Gala wrote:
>> I was wondering if there was some way to make a Kconfig menu either
>> be just a menu or a choice depending on another bool being set or  
>> not.
>>
>> What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I
>> want it so you can only select on option, however if
>> CONFIG_ONLY_HAVE_ONE is not set you should be able to select multiple
>> options.
>
> You can do so using if.
> See following example:
> --------------------------------------------------------------
> config ONLY_HAVE_ONE
> 	prompt "only have one?"
> 	boolean
>
> if ONLY_HAVE_ONE
> config FOO
> 	bool foo
> 	default y
> endif
>
> if !ONLY_HAVE_ONE
> choice
> 	prompt "multiple values"
> 	default VAL_FIRST
>
> config VAL_FIRST
> 	bool "First value"
>
> config VAL_SECOND
> 	bool "Second value"
> endchoice
>
> endif
> --------------------------------------------------------------
>
> You should be able to modify this for the usage you ask for.
>
> Hope this is useful,

It is.

Now is there some way to not have to duplicate the 'config choices  
between if ONLY_HAVE_ONE and if !ONLY_HAVE_ONE

To use your example I want to do:

config ONLY_HAVE_ONE
	prompt "only have one?"
	boolean

if ONLY_HAVE_ONE
config VAL_FIRST
	bool "First value"

config VAL_SECOND
	bool "Second value"
endif

if !ONLY_HAVE_ONE
choice
	prompt "multiple values"
	default VAL_FIRST

config VAL_FIRST
	bool "First value"

config VAL_SECOND
	bool "Second value"
endchoice

endif

I'd like not to have to repeat/duplicate VAL_FIRST, VAL_SECOND, etc..

- k

Re: kbuild question

[Sam Ravnborg]

> 
> Now is there some way to not have to duplicate the 'config choices  
> between if ONLY_HAVE_ONE and if !ONLY_HAVE_ONE
> 
> To use your example I want to do:
> 
> config ONLY_HAVE_ONE
> 	prompt "only have one?"
> 	boolean
> 
> if ONLY_HAVE_ONE
> config VAL_FIRST
> 	bool "First value"
> 
> config VAL_SECOND
> 	bool "Second value"
> endif
> 
> if !ONLY_HAVE_ONE
> choice
> 	prompt "multiple values"
> 	default VAL_FIRST
> 
> config VAL_FIRST
> 	bool "First value"
> 
> config VAL_SECOND
> 	bool "Second value"
> endchoice
> 
> endif
> 
> I'd like not to have to repeat/duplicate VAL_FIRST, VAL_SECOND, etc..

A choice allow you to select multiple values if the type of all
choice entries are of type 'tristate' but this gets enabled
only when CONFIG_MODULES equal to 'y'.
So except if you really need the 'select multiple' when MODULES
are selected I see no easy way to achive what you want.

I did not try but carefull usage of 'depends on' could also help you
but it will get messy quite fast.

Maybe Roman can se a better way?

	Sam

Re: kbuild question

[Roman Zippel]

Hi,

On Thu, 15 Feb 2007, Kumar Gala wrote:

> I was wondering if there was some way to make a Kconfig menu either be just a
> menu or a choice depending on another bool being set or not.
> 
> What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I want it so
> you can only select on option, however if CONFIG_ONLY_HAVE_ONE is not set you
> should be able to select multiple options.

Could you please be more specific about the problem you're trying to 
solve, instead of how you're trying to solve it?
A real example would help a lot to understand the actual problem.

bye, Roman

Re: kbuild question

[Kumar Gala]

On Feb 16, 2007, at 4:23 AM, Roman Zippel wrote:

> Hi,
>
> On Thu, 15 Feb 2007, Kumar Gala wrote:
>
>> I was wondering if there was some way to make a Kconfig menu  
>> either be just a
>> menu or a choice depending on another bool being set or not.
>>
>> What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I  
>> want it so
>> you can only select on option, however if CONFIG_ONLY_HAVE_ONE is  
>> not set you
>> should be able to select multiple options.
>
> Could you please be more specific about the problem you're trying to
> solve, instead of how you're trying to solve it?
> A real example would help a lot to understand the actual problem.

Sure, on powerpc for some of the embedded sub-architectures you can  
only select a single board to build for.  For a lot of people this is  
sufficient, however we are moving towards a world where you can  
easily build in support for multiple boards into a single kernel.

I'd like to have it such that if I'm only building support for one  
board (CONFIG_ONLY_HAVE_ONE, not going to call it that, but for this  
discussion its sufficient), you get a choice menu from Kconfig  
enforcing the ability to only select one board.  However if ! 
CONFIG_ONLY_HAVE_ONE than you can select multiple boards to build  
into your kernel.

if CONFIG_ONLY_HAVE_ONE is set we can optimize out the runtime checks  
that get added for handling the multiple board case.

Hopefully that's clear.

- k

Re: kbuild question

[Roman Zippel]

Hi,

On Fri, 16 Feb 2007, Kumar Gala wrote:

> > Could you please be more specific about the problem you're trying to
> > solve, instead of how you're trying to solve it?
> > A real example would help a lot to understand the actual problem.
> 
> Sure, on powerpc for some of the embedded sub-architectures you can only
> select a single board to build for.  For a lot of people this is sufficient,
> however we are moving towards a world where you can easily build in support
> for multiple boards into a single kernel.
> 
> I'd like to have it such that if I'm only building support for one board
> (CONFIG_ONLY_HAVE_ONE, not going to call it that, but for this discussion its
> sufficient), you get a choice menu from Kconfig enforcing the ability to only
> select one board.  However if !CONFIG_ONLY_HAVE_ONE than you can select
> multiple boards to build into your kernel.
> 
> if CONFIG_ONLY_HAVE_ONE is set we can optimize out the runtime checks that get
> added for handling the multiple board case.

On m68k we have the same problem, but what I'm what I'm considering is to 
add a new mode for choice groups - at least one must be selected and 
kconfig generates the extra information if only one is selected.

bye, Roman

Re: kbuild question

[Sam Ravnborg]

> > 
> > Sure, on powerpc for some of the embedded sub-architectures you can only
> > select a single board to build for.  For a lot of people this is sufficient,
> > however we are moving towards a world where you can easily build in support
> > for multiple boards into a single kernel.
> > 
> > I'd like to have it such that if I'm only building support for one board
> > (CONFIG_ONLY_HAVE_ONE, not going to call it that, but for this discussion its
> > sufficient), you get a choice menu from Kconfig enforcing the ability to only
> > select one board.  However if !CONFIG_ONLY_HAVE_ONE than you can select
> > multiple boards to build into your kernel.
> > 
> > if CONFIG_ONLY_HAVE_ONE is set we can optimize out the runtime checks that get
> > added for handling the multiple board case.
> 
> On m68k we have the same problem, but what I'm what I'm considering is to 
> add a new mode for choice groups - at least one must be selected and 
> kconfig generates the extra information if only one is selected.

How about extendign the current 'option' syntax to do this?
So we could do something like:

choice
	prompt "choice prompt"
	default VAL_FIRST
	option multivalue if !CONFIG_ONLY_HAVE_ONE

config VAL_FIRST
	bool "first"

config VAL_SECOND
	bool "second"

endchoice

It seems to fit well with how option is used today, and extends current
syntax nicely.

	Sam

Re: kbuild question

[Kumar Gala]

On Feb 18, 2007, at 1:25 PM, Sam Ravnborg wrote:

>>>
>>> Sure, on powerpc for some of the embedded sub-architectures you  
>>> can only
>>> select a single board to build for.  For a lot of people this is  
>>> sufficient,
>>> however we are moving towards a world where you can easily build  
>>> in support
>>> for multiple boards into a single kernel.
>>>
>>> I'd like to have it such that if I'm only building support for  
>>> one board
>>> (CONFIG_ONLY_HAVE_ONE, not going to call it that, but for this  
>>> discussion its
>>> sufficient), you get a choice menu from Kconfig enforcing the  
>>> ability to only
>>> select one board.  However if !CONFIG_ONLY_HAVE_ONE than you can  
>>> select
>>> multiple boards to build into your kernel.
>>>
>>> if CONFIG_ONLY_HAVE_ONE is set we can optimize out the runtime  
>>> checks that get
>>> added for handling the multiple board case.
>>
>> On m68k we have the same problem, but what I'm what I'm  
>> considering is to
>> add a new mode for choice groups - at least one must be selected and
>> kconfig generates the extra information if only one is selected.
>
> How about extendign the current 'option' syntax to do this?
> So we could do something like:
>
> choice
> 	prompt "choice prompt"
> 	default VAL_FIRST
> 	option multivalue if !CONFIG_ONLY_HAVE_ONE
>
> config VAL_FIRST
> 	bool "first"
>
> config VAL_SECOND
> 	bool "second"
>
> endchoice
>
> It seems to fit well with how option is used today, and extends  
> current
> syntax nicely.

This works for me, however I dont have the first clue about hacking  
on kconfig code.

I'm happy to test out a patch if one of you guys wouldn't mind  
working something up.. or point me and what I should look at to do this.

- k

Re: KBuild question

[Sam Ravnborg]

On Wed, Mar 02, 2011 at 10:11:46PM +0100, Tom Bart wrote:
> Hello,
> I have spend some time analysing KBuild source files.
Sounds boring :-)

> However there is
> one thing that is not clear for me. In the main makefile I have found
> the following statement:
> 
> Most importantly: sub-Makefiles should only ever modify files in
> their own directory. If in some directory we have a dependency on
> a file in another dir (which doesn't happen often, but it's often
> unavoidable when linking the built-in.o targets which finally
> turn into vmlinux), we will call a sub make in that other dir, and
> after that we are sure that everything which is in that other dir
> is now up to date.
> 
> Kernel is build in a recursive manner. I understand that according to
> the citation firstly all dependencies between different directories
> are identified and then the sub-directory walk through process is
> started. Unfortunately I cannot fine where this functionality is
> implemented? Can somebody point me the right place or maybe my line of
> reasoning is simply wrong?

A typical kbuild makefile fragment looks like this:

obj-y += foo/
obj-y += bar.o

Which tell kbuild to visit foo/ and create a built-in.o there.
And then back and build bar.o.
Finally link bar.o + foo/built-in.o => built-in.o

From the above I think you already grasped this.


In Makefile.lib we process all these variables.
We need to build foo/ before we can link
built-in.o.
So we calculate subdir-obj-y which is the list of files
that are dependent on all directories.
And directories are listed in subdir-ym.

So we have something like:

obj-y        => foo/built-in.o bar.o
subdir-obj-y => foo/built-in.o
subdir-ym    => foo/

In Makefiles.build we then have:

    $(builtin-target): $(obj-y) FORCE
            $(call if_changed,link_o_target)

Which tell us to build all files listed in obj-y and then link built-in.o

    $(sort $(subdir-obj-y)): $(subdir-ym) ;

Tell us we need to visit foo/ to build foo/built-in.o

    PHONY += $(subdir-ym)
    $(subdir-ym):
            $(Q)$(MAKE) $(build)=$@

And here we are told what to do to build in a sub-directory.


So after visiting the foo/ directory we have foo/built-in.o
And we can then link the final built-in.o (assuming we have bar.o)

This is recursive so it may go on at several levels.

If you start to look at modules it becomes a bit complicated...

	Sam

KBuild question

[Tom Bart]

Hello,
I have spend some time analysing KBuild source files. However there is
one thing that is not clear for me. In the main makefile I have found
the following statement:

Most importantly: sub-Makefiles should only ever modify files in
their own directory. If in some directory we have a dependency on
a file in another dir (which doesn't happen often, but it's often
unavoidable when linking the built-in.o targets which finally
turn into vmlinux), we will call a sub make in that other dir, and
after that we are sure that everything which is in that other dir
is now up to date.

Kernel is build in a recursive manner. I understand that according to
the citation firstly all dependencies between different directories
are identified and then the sub-directory walk through process is
started. Unfortunately I cannot fine where this functionality is
implemented? Can somebody point me the right place or maybe my line of
reasoning is simply wrong?
Regards
Tomasz Bartczak