[I wrote]
I guess I wasn't quite clear: my current implementation is both
visibility + value, not visibility only (like current if [ ]) or
value only (like an earlier discussion of dep_if).
[Greg Banks]
Aha. I think you're going to be arguing uphill to get it in.
Could be. Perhaps
Peter Samuelson wrote:
There are lots of instances of things like
if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ]; then
dep_tristate 'Bar' CONFIG_BAR $CONFIG_FOO
...
fi
which can be replaced by
dep_if CONFIG_FOO
tristate 'Bar' CONFIG_BAR
...
dep_fi
Yes,
Peter Samuelson wrote:
My current implementation of if_dep is *not*, as previously theorised,
a drop-in two-way replacement for adding dependencies to the end of
dep_* statements. I currently have it short-circuiting, so statements
are in effect *not* executing in the 'n' case (or the 'm'
Kai Germaschewski wrote:
On Thu, 15 Aug 2002, Peter Samuelson wrote:
The more I think about it, the more I think the default if_dep should
do the m-restricting thing. That way:
dep_bool FOO1 BAR BAZ
dep_mbool FOO2 BAR BAZ
dep_tristate FOO3 BAR BAZ
is exactly equivalent
Peter Samuelson wrote:
[Kai Germaschewski]
I didn't look into like choice statements, but I'd hope it's
possible to add dependencies to them, too, for consistency.
I agree. Actually, if we're changing 'choice' anyway, it should be
redesigned. Status quo takes three arguments:
Peter Samuelson wrote:
My main goal is to make it easier to write Config.in files, by making
the syntax and semantics less awkward. [...]
* The current 'if' statement is really ugly and unintuitive,[...]
Agreed.
* Current 'if' semantics are hard to get right in many common cases.[...]
[Kai Henningsen]
Incidentally, wouldn't it make sense to use dep_if instead of if_dep?
Yes, probably. I'll go ahead and change it in my tree, unless anyone
objects violently.
Peter
---
This sf.net email is sponsored by: OSDN - Tired of
[Greg Banks]
Ok, we need to be a little bit careful about semantics here, or
there is going to be issues converting the existing corpus.
Agreed.
Currently the if syntax and dependencies are not the same thing;
the if condition is purely a visibility limit, and deps are both
value and
[EMAIL PROTECTED] (Greg Banks) wrote on 16.08.02 in
[EMAIL PROTECTED]:
No specific cases, but I was thinking that with your proposed syntax
we'd have a large level of compatibility in both syntax and semantics
between if_dep and dep_bool, much more so than with if and
Incidentally,
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
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
On Wed, 14 Aug 2002, Peter Samuelson wrote:
I've reused the syntax for a dependency line (the tail end of a
dep_bool / dep_mbool / dep_tristate), like so:
if_dep idependency line/i
...
endif
Honestly, I do not like this. It's probably the best that can be done in
shell, but I
On Thu, 15 Aug 2002, Peter Samuelson wrote:
The more I think about it, the more I think the default if_dep should
do the m-restricting thing. That way:
dep_bool FOO1 BAR BAZ
dep_mbool FOO2 BAR BAZ
dep_tristate FOO3 BAR BAZ
is exactly equivalent to
if_dep BAR BAZ
bool
[Kai Germaschewski]
Seeing it from that point of view, it may actually turn into
something which can agree with much more easily.
Great! I've been hoping for your support - not only because I respect
your judgment, but also because Linus takes patches from you. (:
Maybe it actually
Hi,
On Fri, 16 Aug 2002, Kai Germaschewski wrote:
Oh well, I think the only way to find out if all that is really a good
idea is to try, convert some config.in's and look at the result.
I really hate to spoil the fun, but could someone explain to me, why this
is necessary? What problems does
[Roman Zippel]
I really hate to spoil the fun
(:
but could someone explain to me, why this is necessary? What
problems does that fix?
It's not necessary, technically - it doesn't directly fix any bugs.
It falls under cleanup, and as such, it is supposed to make bugs
harder to write and
Hi,
On Fri, 16 Aug 2002, Peter Samuelson wrote:
Basically the current discussion revolves around the best way to
evolve the config language to make it more suitable for its purpose.
This is of course in contrast to what ESR and you have tried, which is
to replace the whole thing.
I haven't
[I wrote]
I've come up with syntax I think I'm happy with.
Thank you one and all for all the discussion and suggestions for
improvement on my proposals. I've incorporated a lot of feedback.
I know I promised to try and come up with a working prototype
including some Config.in files, but some
Greg Banks wrote:
[*] almost enough because I haven't implemented an 'else'
directive. It would be trivial, but I'm not sure what to call it.
'else' itself is a shell primitive, so the shell-based parsers
(Configure, Menuconfig) wouldn't like it.
You will need to implement
Brendan J Simon wrote:
Greg Banks wrote:
[*] almost enough because I haven't implemented an 'else'
directive. It would be trivial, but I'm not sure what to call it.
'else' itself is a shell primitive, so the shell-based parsers
(Configure, Menuconfig) wouldn't like it.
Peter Samuelson wrote:
* 'or' placed between dependencies functions as a logical OR, and
takes very low precedence. This complements the implicit AND
performed between every pair of dependencies.
x or x - x, for any x
n or m == m or n - m
n or y == y or n - y
m
[Brendan J Simon]
Either if_dep, else_dep and end_dep _or ifdep, elsedep, enddep.
I like it. My original if_dep was ifdep, but I thought people would
mistake it for the common verb 'ifdef' and misspell it that way. So I
vote for the _s.
[Greg Banks]
Yes, the _s should be consistent.
Greg, in regards to another question you had - no I don't think there
is value in having a variant if statement that treats 'm' differently.
You can already get the same effect by using 'CONFIG_FOO=y' or
'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
You are much better than I at finding
[Giacomo A. Catenazzi]
I don't like calling it or... It is error prone because it is a non
binary system,
thus can confuse the lazy developers.
I had to call it something. I for one think 'or' is quite intuitive
here. If you insist that OR can only be done on binary values, think
of
[Kai Germaschewski]
Honestly, I do not like this. It's probably the best that can be
done in shell, but I think it's ugly and not intuitive.
I accept that it is not pretty. But unless we can switch to mconfig
or gcml2 or some other static parser for everything, we will need
shell-parsable
Peter Samuelson wrote:
[Giacomo A. Catenazzi]
I don't like calling it or... It is error prone because it is a non
binary system,
thus can confuse the lazy developers.
[...]But
nobody thinks of max as an infix operator, and infix is IMO the most
natural way to express a
[Greg Banks]
I was thinking that with your proposed syntax we'd have a large
level of compatibility in both syntax and semantics between if_dep
and dep_bool, much more so than with if and dep_bool
As you said the other day, This is not a coincidence. (:
But technically, if_dep corresponds
[I wrote]
Mutating the language, long-term, so that it looks less like sh and
more like a specialised language, is IMO a worthy goal. And I think
it can be done. The main thing to deal with is adding an
alternative syntax for 'if' statements which doesn't look like
test(1). More about
Peter Samuelson wrote:
I've come up with syntax I think I'm happy with. It supports most of
the current [ ] based if statement semantics, can be implemented in
shell, and (most importantly for me) drops those $ signs. This lays
the groundwork for stuff like better error checking and auto
29 matches
Mail list logo
