Re: [kbuild-devel] adding a one of the above choice to a choice construct

2004-10-08 Thread Robert P. J. Day
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


Re: [kbuild-devel] adding a one of the above choice to a choice construct

2004-10-08 Thread Roman Zippel
Hi,

On Fri, 8 Oct 2004, Robert P. J. Day wrote:

   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.

So keep it close to the choice, but it doesn't has to be in the choice. 
The Kconfig is a technical description of the kernel dependencies and
technically it doesn't belong there.

   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.

That would be quite careless from your side to move something around 
without checking how it's used.

   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. :-)

There is no guarantee it will continue to work this way and it's also 
quite possible it will subtly break right now.
Sorry, but unless you have technical arguments this won't change.

bye, Roman


---
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