On Sat, 9 Oct 2004, Roman Zippel wrote:
Hi,
Robert P. J. Day wrote:
is there a proper way to place that "calculated" value representing "yes, something non-null was selected" inside the choice construct without getting a kbuild warning? really, that's where it belongs.
Why do you want to put it within the choice? I see nothing wrong with putting it after the choice similiar to PCI access mode choice.
technically, i see nothing wrong with putting it after the choice. aesthetically and philosophically, i'd like to see that sort of thing allowed within the choice since it's so tightly related and, in effect, only *has* meaning in relation to that set of choices.
if it were internal, it means that i could move that choice construct elsewhere -- say to another Kconfig file -- and the calculated variable would move with it. i wouldn't need to remember, oh, there's a calculated variable here as well, right after the choice.
once upon a time, i had a discussion like this on the docbook list, when we were talking about how you'd represent a paragraph opening, followed by a list of steps for how to do something. say,
"if you want to compile a kernel, here's how you do it:
1)
2)
3)
and so on."now, how would you represent that using docbook XML? two possibilities:
<para>
...
<list>
...
</list>
</para>OR
<para> ... </para> <list> ... </list>
most people would agree that the first technique above is a better way to do it, since the list is inherently a subcomponent of the paragraph. the second way might generate the same output, but it suggests that the list is somehow unrelated to the paragraph. i think this is a good analogy for allowing calculated variables within a choice -- because of the tight relationship.
ironically, as i pointed out earlier, if you define that calculated variable within the choice, kbuild will print a couple warnings, but still works just fine. so the functionality is already there, and works correctly. maybe just stop printing the warnings. :-)
rday
p.s. regarding the PCI access mode, i just took a quick look at that, and i think the same argument holds there as well. perhaps it's worth allowing this to be done either way, if that's feasible?
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
