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
