Re: [kbuild-devel] RFC: kernel config: new dependency syntax

2002-08-17 Thread Roman Zippel

Hi,

Peter Samuelson wrote:

 +If the dependency yields m, the first block is executed and the
 +second skipped, just as with y, but with one crucial difference: the
 +output for certain verbs is restricted.  bool and dep_bool
 +statements are suppressed entirely; tristate and dep_tristate are
 +restricted to the two values m and n.  The valid values for other
 +verbs such as define_bool, dep_mbool and hex are not restricted.

Hmm, I should have read the description, instead of the confusing table.
The more formal description I just sent should match this. Anyway, I
don't know if it's really that a good idea to introduce tristate logic
into if statements like this. I suspect it will confuse a lot more
people.
Something like:

if_dep dep
  stmt1
else_dep
  stmt2
fi_dep

could be transformed into

stmt1 dep
stmt2 dep!=n

Is that really intuitive?

bye, Roman


---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel



Re: [kbuild-devel] RFC: kernel config: new dependency syntax

2002-08-17 Thread Roman Zippel

Hi,

Peter Samuelson wrote:

 +If you think in terms of Boolean algebra, most of the above rules make
 +sense if you think of each primitive value (y, m and n) as two
 +bits: y=11, m=01, n=00.  Adjacent words are implicitly ANDed
 +together, and the or statement, with lower precedence, performs an
 +OR between lists of words.  The ! operator does not quite fit this
 +explanation, because !m = m, but that was specified for practical
 +reasons, to cover a common case in kernel configuration.

Simply define y=2, m=1, n=0, then you can define:
x  y == min(x, y)
x || y == max(x, y)
!x == 2-x
As soon as you have to deal with more complex expressions or even
expression transformations, that will make a lot of sense. :)

 +|Value of the if_dep dependency line
 +  Statements in |(nested restrictions are cumulative)
 +  the blocks|  y   |  n   |m
 +  --+--+--+---
 +  bool, |  |  | suppressed in
 +  dep_bool  |  |  | both blocks
 +| unrestricted | suppressed   |
 +  --+ in if_dep| in if_dep+---
 +  tristate, | block,   | block,   | restricted to {m,n} in
 +  dep_tristate  | suppressed   | unrestricted | if_dep block, suppressed
 +| in else_dep  | in else_dep  | in else_dep block
 +  --+ block| block+---
 +  all other |  |  | unrestricted in if_dep
 +  verbs |  |  | block, suppressed in
 +|  |  | else_dep block
 +

The last coloumn makes no sense. if requires a boolean value, so you
have to convert the tristate value. This means if_dep e.g. becomes if
(dep) != n and else_dep if (dep) == n and to the dependency list you
had to add dep and !dep respectively.

bye, Roman


---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel