* kbuild question
@ 2007-02-15 19:18 Kumar Gala
2007-02-15 22:33 ` Sam Ravnborg
2007-02-16 10:23 ` Roman Zippel
0 siblings, 2 replies; 11+ messages in thread
From: Kumar Gala @ 2007-02-15 19:18 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linux Kernel list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kbuild question
2007-02-15 19:18 kbuild question Kumar Gala
@ 2007-02-15 22:33 ` Sam Ravnborg
2007-02-15 23:44 ` Kumar Gala
2007-02-16 10:23 ` Roman Zippel
1 sibling, 1 reply; 11+ messages in thread
From: Sam Ravnborg @ 2007-02-15 22:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linux Kernel list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kbuild question
2007-02-15 22:33 ` Sam Ravnborg
@ 2007-02-15 23:44 ` Kumar Gala
2007-02-16 8:50 ` Sam Ravnborg
0 siblings, 1 reply; 11+ messages in thread
From: Kumar Gala @ 2007-02-15 23:44 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linux Kernel list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kbuild question
2007-02-15 23:44 ` Kumar Gala
@ 2007-02-16 8:50 ` Sam Ravnborg
0 siblings, 0 replies; 11+ messages in thread
From: Sam Ravnborg @ 2007-02-16 8:50 UTC (permalink / raw)
To: Kumar Gala, Roman Zippel; +Cc: Linux Kernel list
>
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kbuild question
2007-02-15 19:18 kbuild question Kumar Gala
2007-02-15 22:33 ` Sam Ravnborg
@ 2007-02-16 10:23 ` Roman Zippel
2007-02-16 14:14 ` Kumar Gala
1 sibling, 1 reply; 11+ messages in thread
From: Roman Zippel @ 2007-02-16 10:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: Sam Ravnborg, Linux Kernel list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kbuild question
2007-02-16 10:23 ` Roman Zippel
@ 2007-02-16 14:14 ` Kumar Gala
2007-02-18 17:16 ` Roman Zippel
0 siblings, 1 reply; 11+ messages in thread
From: Kumar Gala @ 2007-02-16 14:14 UTC (permalink / raw)
To: Roman Zippel; +Cc: Sam Ravnborg, Linux Kernel list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kbuild question
2007-02-16 14:14 ` Kumar Gala
@ 2007-02-18 17:16 ` Roman Zippel
2007-02-18 19:25 ` Sam Ravnborg
0 siblings, 1 reply; 11+ messages in thread
From: Roman Zippel @ 2007-02-18 17:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: Sam Ravnborg, Linux Kernel list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kbuild question
2007-02-18 17:16 ` Roman Zippel
@ 2007-02-18 19:25 ` Sam Ravnborg
2007-03-15 15:22 ` Kumar Gala
0 siblings, 1 reply; 11+ messages in thread
From: Sam Ravnborg @ 2007-02-18 19:25 UTC (permalink / raw)
To: Roman Zippel; +Cc: Kumar Gala, Linux Kernel list
> >
> > 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kbuild question
2007-02-18 19:25 ` Sam Ravnborg
@ 2007-03-15 15:22 ` Kumar Gala
0 siblings, 0 replies; 11+ messages in thread
From: Kumar Gala @ 2007-03-15 15:22 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Roman Zippel, Linux Kernel list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: KBuild question
2011-03-02 21:11 KBuild question Tom Bart
@ 2011-03-02 21:40 ` Sam Ravnborg
0 siblings, 0 replies; 11+ messages in thread
From: Sam Ravnborg @ 2011-03-02 21:40 UTC (permalink / raw)
To: Tom Bart; +Cc: linux-kbuild
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* KBuild question
@ 2011-03-02 21:11 Tom Bart
2011-03-02 21:40 ` Sam Ravnborg
0 siblings, 1 reply; 11+ messages in thread
From: Tom Bart @ 2011-03-02 21:11 UTC (permalink / raw)
To: linux-kbuild
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-03-02 21:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-15 19:18 kbuild question Kumar Gala
2007-02-15 22:33 ` Sam Ravnborg
2007-02-15 23:44 ` Kumar Gala
2007-02-16 8:50 ` Sam Ravnborg
2007-02-16 10:23 ` Roman Zippel
2007-02-16 14:14 ` Kumar Gala
2007-02-18 17:16 ` Roman Zippel
2007-02-18 19:25 ` Sam Ravnborg
2007-03-15 15:22 ` Kumar Gala
2011-03-02 21:11 KBuild question Tom Bart
2011-03-02 21:40 ` Sam Ravnborg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.